Since 8th of july 2011, the product group has published a new post regarding changes on database size limitations and guidance.

The most interesting key points out of the above mentioned post are as follows:

1. For a SharePoint content database up to 200 GB  there are no special requirements and this limit is included for consistency.
2. For a SharePoint content database up to 4 TB you need to additionally plan for the following two requirements:

   • Requires disk sub-system performance of 0.25 IOPS per GB, 2 IOPS per GB is recommended for optimal performance.

   • Requires the customer to have plans for high availability, disaster recovery, future capacity, and performance testing.

   • And you need to review additional considerations in the TechNet Boundaries and Limits article.

3. For a SharePoint content database over 4TB specifically for a Document Archive scenario you are required to additionally plan for the following:
   • SharePoint sites must be based on Document Center or Records Center site templates and must be an archive scenario where less than 5% of content is actively read from each month and less than 1% of content is actively written to.
   • Do not use alerts, workflows, link fix-ups, or item level security on any SharePoint objects in the content database. Note: document archive content databases can be the recipient of documents as a result of Content Routing workflow.
4. Other specific limits changes being made at the same time:
   • A new limit of 60million items in any one SharePoint content database
   • The specific 5 TB limit per SQL Server instance has been removed.  Instead you should work with a SQL Server professional to plan for database storage.

Please review the full TechNet Article SharePoint Server 2010 capacity management: Software boundaries and limits document.  We have also published a guide on SharePoint 2010 scalability here: http://go.microsoft.com/fwlink/?LinkId=223599. In the near future we will publish a test report of large scale testing that supports these new size limits.

Also added by Stefan Goßner (thnx for admission to repost),  the information to the official statement about RBS:

1. "We are clarifying that Remote Blob Storage (RBS) does not offer a way to increase the SharePoint content database size limits. The content database supported size limits apply to the sum of data stored in SQL Server plus data stored outside of SQL Server using an RBS provider. A description and the value of RBS is detailed in the team blog post."
2. "The Microsoft SQL Server FILESTREAM RBS provider is now supported allowing for iSCSI connections to lower cost NAS storage. The SQL Server RBS provider is one option for RBS use with SharePoint and there are a number of ISV’s who also have RBS providers."

See Stefan's full post's here:
http://blogs.technet.com/b/stefan_gossner/archive/2011/07/08/paul-andrew-talks-about-new-larger-sharepoint-content-database-size-limits-and-rbs-clarifications.aspx 
http://blogs.technet.com/b/stefan_gossner/archive/2011/06/23/sharepoint-2010-rbs-documentation-has-been-updated.aspx

More from the SharePoint Team Blog:  The following considerations have to be taken into account when using RBS with SharePoint:

• RBS enables SharePoint Foundation 2010 running on SQL Express to store more data than the SQL Express limit of 4 GB. In SQL Express 2008 R2 this limit was increased to 10 GB.
• Some operations can be performance optimized with average blob sizes over 1Mb. This result is from tests with the SQL RBS Provider. Ref: http://msdn.microsoft.com/en-us/library/cc949109(SQL.100).aspx
• There could be storage optimizations with potential disk space and disk cost savings from differential backups or tiered storage.
• We have completed testing on the SQL RBS FILESTREAM provider which can enable iSCSI connected storage for RBS use. Using iSCSI allows for the use of lower cost NAS storage.
• Other potential data optimizations may be developed by ISV’s using the supported public RBS APIs and SharePoint APIs.
• Backup strategy must be carefully considered. Both document metadata and document BLOBs must be backed up at exactly the same point in time. This means any third party backup solution needs to be capable of restoring both the SQL database used by SharePoint and the BLOBs used by SharePoint as a set where no variance occurs which would have the database reference BLOBs that are not available from the same backup.
• RBS is most likely to be used for document archive scenarios where documents are written and not updated. BLOBs in RBS are never updated once they are written; instead a new BLOB is created for any update. BLOBs are immutable, old BLOBs are garbage collected later. You can read more about RBS garbage collection in this article: http://technet.microsoft.com/en-us/library/ff628583.aspx
• RBS providers are required to return the first byte of data in a request in 20ms. This applies for all requests between SharePoint and the RBS provider storage layer.
• The SharePoint database is not intended to be read from or written to except by SharePoint. RBS providers don’t have separate access to the data. This includes direct access to blobs. Ref: http://support.microsoft.com/kb/841057/en-us
• Performance may decrease for smaller BLOB sizes when using RBS. This is also shown in the “FILESTREAM Storage in SQL Server 2008” article referenced above.
• There are many RBS providers available and customers should evaluate them for suitability for their implementations.

Please  see more details and the “Q & A” section on the original post from the SharePoint Team Blog: http://sharepoint.microsoft.com/blog/Pages/BlogPost.aspx?pID=988

  Move-SPSite cmdlet extended with a new parameter!

Another important info is the new added parameter [RbsProviderMapping], which was added in Microsoft SharePoint Server 2010 with Service Pack 1 (SP1) and Microsoft SharePoint Foundation 2010 with Service Pack 1 (SP1).
This parameter is used to move an RBS-enabled site collection from one RBS-enabled content database to another RBS-enabled content database without moving the underlying BLOB content. If the content database has more than one RBS provider associated with it, you must specify all providers. The same providers must be enabled on the target content database and the source content database.

Other related blogs and posts:

Announcing: New Larger Content Database Size Limits and RBS Clarifications by Paul Andrew

Now Serving Larger Databases… by Bill Baer