The recent post from the SharePoint Product Team blog on  has caused quite a stir.

This is not least because in specific scenarios, Microsoft have confirmed that they will support customers with content databases that are between 200GB and 4TB in size, and in one scenario have removed the SharePoint supported limitation altogether (thus meaning that customers will be limited to the ).

I encourage you to read through the barrage of decent information that has already been published online, including:

•  from Microsoft – this is the post that everyone is talking about.
•  from Paul Andrew.
•  From Joel Oleson.
•  From Wictor Wilén

Whilst the SharePoint Product Team blog includes details around using the SQL RBS FILESTREAM provider to enable iSCSI connected storage (and therefore lower cost NAS storage), the focus of this post is on the sizing recommendations.

Before I begin note that none of the information below is official – it is simply my own interpretation of the recent guidance.

A step back

Let’s start by rewinding a couple of weeks. Way back then, there were some heated debates on Twitter and various forums surrounding the 200GB supported content database limitation. In particular, the main theme was whether or not customers could use RBS to get around this limit.

This is largely because prior to the SP1 guidance, we only had a 200GB supportability limit to work toward for collaboration scenarios which lead customers to question the scalability of SharePoint. It seemed logical to conclude that – given the 200GB limitation – storing BLOBs outside of the SQL DB would mean that only metadata stored within the DB itself would count towards that limit. This misconception was encouraged by a lack of guidance from Microsoft (the  made no mention of RBS) and no concrete explanation around the sizing limits.

The options for customers were limited to:

1. Assuming that RBS provided a means of bypassing the 200GB limitation and scaling up or,
2. Assuming that the 200GB limitation included metadata and BLOBs, regardless of BLOB location and scaling out by creating new Content Databases.

I think it’s worth mentioning at this stage that the advice back then was – and still is – to ensure that site collections remain below 100GB in order to allow for backup/restore operations. The one exception to this is where a site collection is the only one stored within a content DB, in which case the size of the site collection is limited to the size of the content DB and backup/restore operations must be taken at the SQL DB level.

OK, what about this 4TB business?

Fast forward to today and we have some new guidance from the SharePoint Product Group based on lessons learned over the last 12 months. Rather than regurgitate this information I refer you to the links at the top of this post, and have attempted to provide a summary of the sizing changes:

* “Highly Optimised” refers to the guidance contained within the document. In particular, the Content Database Limits section lists specific requirements that need to be met.​

There are a few points to note in the above table:

• The original 200GB recommendation remains for the majority of scenarios.
• The new supported scenarios only apply to optimised environments.
• There are no changes in terms of site collections limits.
• RBS doesn’t change any of the sizing recommendations.

Hang on; RBS makes no difference to content DB sizing?

Here is the  from Microsoft:

“The content database size includes both metadata and BLOBs regardless of where the BLOBs are located and use of RBS does not bypass or increase these limits.”

I think the formula below helps simplify this statement:

Content database size == [Metadata + BLOBs], regardless of where the BLOBs are stored.

This is not new and was the case prior to the SP1 guidance.

Although this is a gross oversimplification (I deliberately miss off various GUIDs including those that identify the SPSite objects), let’s look at a straightforward example to illustrate this:

In this example, we have reached the supported “Content database size” limitation for a typical collaboration usage scenario. Without a highly optimised SQL Server environment and advanced disaster recovery story we will need to scale out by adding additional content databases and potentially moving site collections using Move-SPSite.

Limits apply at the abstracted level, i.e. SPContentDatabase and SPSite, so although in the above scenario the actual SQL Content DB is only 10GB in size (the metadata in this case makes up for 5% of SPContentDatabase), the “Content Database Size” as far as SharePoint is concerned is 200GB so we have reached the supported limit for environments that do not meet the SQL Server optimisation requirements.

So… what’s the point of RBS?

We now know that RBS is not there to help us get around the content DB sizing limitations – those of you who have deployed RBS knew that already though, right? :-).

For those of us that haven’t, and are considering RBS for our environments, let’s walk through a few valid scenarios based on the Product Teams blog:

• Taking advantage of commodity storage – this is the key scenario and the new support for iSCSI connected storage improves this story.
• Document Archive scenarios – BLOBs are immutable so frequent writes can reduce performance.
• Getting around the 10GB content DB limitation imposed by SQL Server 2008 R2 Express: FILESTREAM data doesn’t count toward the limit.
• Improving performance where BLOBs are, on average larger than 1MB (if average BLOB size is below 256KB they may as well be stored in-line; 256KB-1MB is a grey area and it depends on your environment).
• [11/07/2011]​ Enhancing maintainability: 
  • Improving performance during index rebuild maintenance tasks.
  • Reducing the effective size of the SharePoint content database and backup size.
  • Reduced transaction-log-write overheads, the benefit of which will depend on the frequency with which you truncate the transaction log during a backup.

Another benefit offered by RBS is the capability to perform shallow copies whilst using the Move-SPSite cmdlet. This can be a big time saver if you frequently migrate site collections between content databases, and was added in  In essence, structured data is moved between content databases whilst unstructured data (remote BLOBs) remain untouched.

Wrap up

• The new supported limits are great news for customers with highly optimised SQL server environments and an advanced disaster recovery strategy.
• For the general usage scenarios, 200GB is still king and environments can scale out by adding additional databases.
• The content database sizing recommendations apply at the SharePoint Content Database (SPContentDatabase) level, not SQL DB level.
• There are several scenarios in which RBS can be useful but bypassing the supported DB sizing limits is not one of them.

Further reading:

 [11/07/2011]