Probably one of the worst KB articles I have seen lately introduces, what has the potential to be a really exciting new feature of WSS 3.0/4.0 – Remote Blob Storage (RBS). This interface allows the storage of "blobs" outside of SQL server in a kind of BlobBank (I call dibs on this name. J). Blobs are the stream of content, a byte[] for those dev heads, which represent files within SharePoint. They are stored alongside their metadata in SQL. Having the ability to move these blogs to external storage systems is a huge win for some whom have TB of SQL storage and whom want to reduce the dependency on SQL for this type of storage.

Simon Skaria plans on blogging about the interface so I will not go into that here however what I did want to cover were some of the pros and cons or as some would say "considerations" when evaluating the Remote Blob Storage API.

Pros

1. Ability to use storage other than SQL Server for blobs.
2. Ability to leverage a lower TCO storage solution for blobs. This point should be scrutinized for each enviroment especially when you consider some of the Cons pointed out below.

Cons

1. Without ISV involvement there is no mechanism to ensure Backup and Restore is consistent between SQL and external storage solution. Since part of the blob, the ID is still stored in SQL and the blob itself is stored elsewhere these items must remain in a consistent state. So bottom line here is you must be careful when planning your backup and disaster recovery strategies.
2. Lack of documentation.
3. Depending on the external solution chosen it may be slower than SQL which would have obvious impact to the performance.
4. The provider works at the farm level only.
5. Removing the provider once deployed is going to be a huge problem should one need to back out.
6. This is custom code that runs all the time within SharePoint; if there is a performance problem, memory leak, etc it will impact SharePoint stability greatly.
7. The O12 implementation is not fully baked and will very likely change for O14. So the likelihood that an O12 provider will need to be rewritten for O14 is very probable.
8. There is no migration path for the provider in an existing SharePoint deployment. New blobs will be stored with your provider while existing blogs will remain in SQL. You may touch the blogs and cause them to be migrated however that has a whole set of other problems.
9. To date there is very little experience rolling out this API. So the real world knowledge is very tribal deep within MSFT and not likely to make it into the public domain in any quick manner.
10. While the API will be supported however it is highly unlikely the support teams will have training or knowledge about its proper use.
11. It is very unclear what the experience will look like while upgrading an O12 using this solution to O14.

BTW if anyone writes a provider I would love to hear about it!

Thanks
Todd