One of the new things in SQL Server 2008 R2 is Remote Blob Storage (RBS) which allows admins to setup SQL to save data that would normally go into a BLOB field to be stored somewhere else using an RBS provider. This provider could store data on a cheaper disk solution (compared to the expensive disk solutions usually selected for SQL Server), to a SAN or maybe even into the cloud… it really doesn’t matter where. The point is that BLOBs can be kept out of a SQL Server DB.
For SharePoint this has big implications because as a document/attachment centric product, it stores a LOT of data in BLOBs generating large content databases. For a while people have asked if you could store that data outside of SQL which was pretty much not the case. OK, we did have External Blob Storage (EBS), but it was not recommended.
SharePoint 2010 when combined with SQL Server 2008 R2 allows you do RBS so you can keep everything in your content DB’s except the BLOBs. However this shouldn’t be a knee jerk decision…
One thing I’m seeing in many developer sessions I do are developers asking this same question and when you explain what RBS is and how it works, many folks jump on it. However this should be something that is discussed and debated with your SQL Server admins & server admins. Why?
Think about the backup & restore story. You need to make sure the backups of both your SharePoint servers, content databases and now, if you’re employing RBS, the place where the blobs are stored. Considering SharePoint is a collaborative solutions and those who are looking to employ RBS are usually those with heavy SharePoint investments & high usage. Therefore you need to carefully coordinate the availability of the SQL Servers as well as the underlying BLOB storage as well as the backup strategy.