Joel Oleson's Blog - SharePoint Land

How large for a single SharePoint content database?

I think my a post or second hand PPTs in the past may have confused some people about a capacity planning recommendation I've made.  I have in the past said to plan for 50GB databases.  This is not a scalability limit.

Based on a recent thread with some project managers in the product team.  I'm getting back some second hand information that people are thinking these numbers are hard coded or hard limits in the product.  This is NOT the case.  Let me give you a few examples of large databases I'm aware of.

http://office  Internally at Microsoft there's a portal called Office.  They had a 500GB database before they split it.  This single database grew for years before they moved sites into separate databases.  There are a few reasons you'd want a single database.  Sure it's easy to keep track of, there's only one.  If you're doing log shipping, its much easier to configure.  If you're not moving it, backing it up locally, it's not much of a problem.

http://team Internally we had a 200GB database with a few thousand WSS v2 sites collections.  You've seen the split tool that we used to move this into databases.  Now there are over 60 content databases for the over 3 TB of data on this single web application/(IIS virtual server).

Why would I recommend splitting the databases if you could have a single TB database with 50,000+ site collections?  Because you can.  I don't want to wrestle with someone over scalability when I'm one that preaches that SharePoint can scale 10X more than anyone's ever tried to push it.  I seriously believe that properly tunned we can see SharePoint 2003 farms in the 10's of TBs and SharePoint 2007 in the 50-100TB range.  There aren't hard limits on the database side.  You can have multiple SQL clusters with TBs of content behind each of them with thousands of connections per box.  With the caching features in SharePoint Server 2007 or the third party devices from the likes of Certeon or Tacit Networks.  You could see how large corporations can scale past the hundreds of thousands of users distributed around the planet.

Arguments for large databases are things like SQL log shipping and snapshots.  You could log ship your data to a hot swap or warm standby.  You could snap your TBs of data in a few minutes, and quickly snap back if needed.

I don't want to hear that 50GB is a limit, its more of a preference for 1 database for many based on common configurations.  Remember that adding additional content databases doesn't mean adding additional web applications.  A single web application can easily support 30 content databases.

In recent conversations at Tech Ed and at the SharePoint conference I've ran into SharePoint consultants who do recommend 50GB databases.  They've been through the pains of restoring a database and wished it was smaller or broken up for quicker restore or had a customer ask them how to resolve their database backup window issues.  More databases, more threads offers the flexibility for this need.

So, when someone asks you how large of a database can SharePoint support, know that it's not 50GB.  The product team doesn't give you a limit, because there isn't one.  SQL Server 2005 on the latest and greatest x64 hardware is the current limit, whatever it can support... and you know they've been supporting Terabyte databases for years.

I think the best recommendation is to talk to your SQL folks.  Find out what size of databases they can manage or prefer to manage.  Then take the Terabytes of content and divide it by that number.  Managing content databases doesn't need to be scary.

Further threads with the Dev/PM team led to some further guidance which I've posted to the SharePoint team blog...

The SQL team has posted some upper limits on database sizes.  My no restrictions for SharePoint first pass could be seen as misleading.  Looks like you're limited not to a petabyte but 1 Exebyte, but you do need to break these into different files of a maximum of 16 Terabytes each.

<update> 

Looking for WSS 2.0 database split tools?