Does writing a custom RBS provider force one to put SharePoint into unsupported state?

Question

It is well known that modifying a content database directly by running direct SQL queries results in an unsupported SharePoint state. However, it is possible to develop custom RBS providers. Note that when an item is moved to RBS, RBS provider (e.g. FILESTREAM) creates a blob in the RBS, then sets Content in AllDocStreams table to NULL and RbsId to the generated blob id:

(Image source: http://blogs.technet.com)

Now, RBS API makes it possible to create blobs in RBS and generate blob ids, but there is no mechanism available that would actually update the SharePoint content database correctly after this step. So it seems to me that a developer is forced - after a blob has been created and its id generated - to update the content database directly through SQL, i.e. update Content to NULL and assign the generated RbsId. This seems to be the only way of implementing a custom RBS provider, yet it directly contradicts the requirement that content database should only be touched through the SharePoint API.

Am I missing something or is a developer indeed forced to cause unsupported state when developing a fully-functional custom RBS provider? Or would it only be considered unsupported if it prevented a resolution of a potential issue?

Answer 1

If you go about it the right way by using farm solutions and the standards I don't think you will have a problem. It would be if you're modifying base code for SharePoint itself or the database structure overall where you would probably run into problems getting support. Microsoft will probably NOT support your custom RBS solution, though. We use a product called "StoragePoint" from Metalogix which is a custom RBS provider (among other things) and I've had no problems getting support from Microsoft.