The content database conundrum
Content databases contain site collections. A site collection doesn't span content databases; it lives within the one database. SharePoint 2010's original size limits were 200GB for collaboration content and 1TB for document archive content -- regardless of whether your content was in the database itself or lived in an NTFS folder through Remote Blob Storage support (a blob is a binary large object). These limitations often forced administrators to create additional content databases and site collections for the sake of breaking up the location of their data.
Remote Blob Storage allows content that would normally be housed in a content database (such as documents and video) to be stored in another location, such as an NTFS folder. This is a welcome feature in SharePoint 2010 because administrators were sometimes uncomfortable with documents and such being stored in SQL.
With the release of SharePoint 2010 SP1, the general usage scenarios remain the same for content databases. However, there is now a secondary supported path that says as much as 4TB are supported per content database if your disk subsystem's performance is at least 0.25 I/O operations per gigabyte; 2 IOPs per gigabyte is recommended for optimal performance. In addition, you must have developed plans for high availability, disaster recovery, future capacity, and performance testing (according to TechNet's latest capacity management information).
At the same time, there are no explicit content database limits if the content database is for document archiving -- if you meet the requirements I've mentioned. You must also have sites based on the Document Center or Records Center site templates. The reason document archives have no explicit limits is that this content is not accessed often, so the performance issues that gave rise to the limits usually don't apply. The lack of explicit limits for document archiving assumes that less than 5 percent of the content is accessed each month and less than 1 percent is modified or written each month. You also would not want to use alerts, workflows, link fix-ups, or item-level security on any objects in this content database.
You might be thinking, "Wow, with no limitation I could really grow this out of control, especially using Remote Blob Storage to have my content sit in an NTFS folder. If only network-attached storage was supported." The good news is that NAS is now supported with Remote Blob Storage as long as it takes no more than 20ms from the time SharePoint Server 2010 requests a Blob until it receives that first byte from the NAS.
SharePoint 2010 SP1 doesn't bring game-changing features, but it doesn't need to. SharePoint 2010 itself was that game changer, and what we need now are reasonable enhancements -- exactly what Microsoft has delivered in SharePoint 2010 SP1.
This article, "SharePoint 2010 SP1: What it does -- and does not do," was originally published at InfoWorld.com. Read more of J. Peter Bruzzese's Enterprise Windows blog and follow the latest developments in Windows at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.