So "SharePoint Server 2010 capacity management: Software boundaries and limits" says about the 200GB limit:

If you are using Remote BLOB Storage (RBS), the total volume of remote BLOB storage and metadata in the content database must not exceed this limit.

The official FAQ: SharePoint 2010 Remote BLOB Storage (RBS) unfortunately doesn't explain my question:

When I store blobs via the SQL FILESTREAM RBS provider (that would mean that those files are stored somewhere locally on C:\files), the content database is rather small (as there are only references to the BLOBs), correct?

Does Microsoft mean with the above quote that the content database still has to be below 200GB, but if you have 600TB of data on C:\files and reference them via RBS and said content DB everything is good?
In other words: Can I have more content than 200GB with RBS when the content DB stays below 200GB?

2 Answers 2


Short answer, the quote above does say RBS and the content database must not exceed the limit. Not just the content DB when RBS is used.

Database size is such a gray area with SharePoint. MS's recommendation of 200GB is to ease the maintenance of the database.

"Content databases exceeding 200 GB and up to 4 TB support much of the same flexibility as content databases <200 GB. However, additional planning should be considered in order to effectively manage those databases in respect to operational and hardware considerations."

from Managing Multi-Terabyte Content Databases with Microsoft SharePoint 2010

  • 1
    I don't read it as "the total volume of remote BLOB storage [in the filesystem via FILESTREAM] and metadata in the content database". I read it as BLOBS+metadata in the database shall not exceed the 200GB limit. The default RBS provider saves the blobs in the database (hence the database will just stay large). The FILESTREAM RBS provider saves the files in the local file system, hence the database stays small. With FILESTREAM there is only a pointer in the DB: simple-talk.com/dotnet/.net-tools/…
    – Dennis G
    Commented Feb 21, 2012 at 16:07
  • My understand of RBS, is that FILESTREAM has to be configured for it to be effectively remote... I assume RBS is using FILESTREAM. Commented Feb 21, 2012 at 16:11
  • Regardless, taking into MS's concerns with large databases, I would say that the same concerns applies to large RBS stores: maintenance (backup, restore, etc). Larger it gets, the more considerations you have to make for hardware, uptime, SLA, etc. Commented Feb 21, 2012 at 16:12
  • You're perfectly correct about that - I just don't understand why MS would limit the size of your large objects residing on some other store (harddrive) than the content DB. SharePoint in the end only sees the content DB and shouldn't care what the SQL server is doing with the files, should it?
    – Dennis G
    Commented Feb 21, 2012 at 16:20
  • From what I have gathered, SharePoint doesn't care about the database size. It starts to care about number of rows and columns, but only when it comes to performance. And that's the same reason MS cares about database sizes:performance. There are techniques available to increase performance of larger database sizes (notes in the prev posted whitepaper). The only serious limitations will be the hardware and the version of SQL you're running on. Commented Feb 21, 2012 at 16:26

MS recommends a 200 GB size limit for each content DB. The article you mentioned is baddy wording the recommendation.

RBS is a remedy to content DBs growing extremely large.

Using RBS, will allow you to move the unstructured data (BLOBs) out of the content DBs. So this will shrink your content DBs tremendously. That means you have a content DB that has size of 200 GB that references BLOBs on a file system with a size of, let say, 1 TB.

  • 2
    Sorry, no. At least not with the default FILESTREAM provider. When using third party or your own RBS provider this is the way to go, correct. But the recommendation of 200GB includes the RBS stored content (I have confirmation of this from MS). This is crazy, I know, but the way it is.
    – Dennis G
    Commented Jun 21, 2012 at 19:26
  • Then, I misread it. The only reasons that I see MS statement makes sense is having a content DB and BLOB storage of 200 GB+ will increase the backup and restore time. Also, if you perform the detach content DB upgrade approach, the upgrade process will take a long time.
    – Hossein A
    Commented Jun 21, 2012 at 20:18
  • Look at the whitepaper I posted - actually you can have content databases (multiple terabytes). The only problem is that this is not "supported" out of the box. In other words you will need some experienced DBOs (as it's all about the database) which can monitor the health of your DB and all connected systems. And yes, as the database backup uses shadow copies it gets a problem round about 200GB - hence the limit as you can't use the "regular dumb" backup anymore.
    – Dennis G
    Commented Jun 21, 2012 at 20:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.