Implement FILESTREAM for blobs into Azure Blob Store
Storing blobs in the database is fairly pointless when you have a dedicated blob store. Implement the FILESTREAM protocol to store blobs in a user's azure storage
This is not currently planned at this time. Will keep this item open for voting and comments.
Ryan Singer commented
Without FILESTREAM delete operations against tables with lots of large BLOB data take far longer.
Our on-prem DB performs deletes many orders of magnitude faster because of this. A delete operation that takes 20:02 in azure sql takes 6 seconds on-prem because we can use FILESTERAM to make the BLOB deletion asynchronous.
Perhaps most importantly we gain this performance with almost no code changes required as the sync is handled by the database, instead of our code.
This feature seems like a no-brainer if you want people to move from on-prem to PaaS.
Currently, when you have an OnPremises SQLServer, you've got the whold disk, and can use it any way you want. Storage becomes essentially free.
However, with AzureSQL I pay through my nose for storage, so this is not an option.
So, please either make a FILESTREAM scenario possible with BLOB storage, Azure Files or an Azure Disk, or provide a way of billing LOB storage segments differently.
David Verschoor commented
This is like one of the most baffling features not yet implemented, a native Azure SQL -> blob storage integration is a huge advantage for small developers trying to a get an attachment system working quickly compared to other solutions.
Granted, managing syncing here is tough, but even a non-syncing solution (just storing a connection string to the Azure blob) already saves a lot of code.
Pond Fish commented
Whether it uses FILESTREAM or not, Azure SQL and Managed SQL should handle large amounts of blob data effortlessly. Maintaining references to externally stored blobs is a natural way to do this, whether stored in Azure Blob Store or some other external file repository. But until SQL exhibits competency in storing blobs in its database file, it should have some method to store references to them but store the blob data using a fast external method.
Marcel Isler commented
One of the main benefits of using FileStream is that your blob data and the corresponding database record don't get out of sync. If you have to use two separate systems to store blobs with related data, you have to write a lot of code just to keep them in sync, and deal with all the possible scenarios where one or the other might have an issue.
Crusader General commented
This is a critical feature. It SHOULD BE your top priority !!
Jens Theisen commented
@Ryan This is something that about everybody needs, in contrast to all the big data stuff that's being done on top of SQL Azure instead.
Yes, this would be used greatly
I recently upgraded a project to store files in an SQL2014 FileTable, instead of storing the files separately and then just referencing in the database. This has allowed for some significant improvements in site management. It's just unfortunate that at the moment this prevents me from easily moving the site from a dedicated VM to an Azure Web Service. FileTable's and FileStream's are a fantastic feature. I really hope that these will eventually be supported natively by Azure SQL.
Michael LeValle commented
Any movement on this?
Love to see that!
Not because of retrieval speed (varbinaty vs filestream) but because then a retrieval of an object via entity framework, which typically retrieves all fields, would not retrieve the FILESTREAM data and so save a lot of time and bandwidth.
Put my vote on the list for that too.
In Azure, filestream doesn't make sense, but a BLOB data type using BLOB storage would be great.
Does Microsoft already have a position about this in 2015?
a great think about storing files with filestream is to use the same database transaction all over the code and don't care if something goes wrong, because you can just rollback.
Brian McKinley commented
This should include the ability associate a storage account with database, federation or federation "member." If a database, federation or federation member is dropped the associated blobs referenced in the tables should be deleted automatically from the blob storage. When a federation is split we should have the option to specify a new storage devices for the new federation member at the same time.
Daniel Kornev commented
Totally agree; enabling FileTables as part of SQL Azure would also enable full-text search and semantic search scenarios.
Ryan CrawCour commented
Why would you want to store blobs in SQL Azure when storing blobs in Windows Azure Blob storage is orders of magnitude cheaper. Store your relational data in SQL Azure and your blobs in a storage abstract designed for this exact purpose.
Why use a separate API for Azure storage when we can use ADO.Net and get at SQL AND file data?