How can we improve Azure SQL Database?

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

866 votes
Sign in
Sign in with: oidc
Signed in as (Sign out)
You have left! (?) (thinking…)
anonymous shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: oidc
Signed in as (Sign out)
  • Anonymous commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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.

  • Jens Theisen commented  ·   ·  Flag as inappropriate

    @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.

  • Eugene commented  ·   ·  Flag as inappropriate

    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.

  • Anonymous commented  ·   ·  Flag as inappropriate

    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.

  • Anonymous commented  ·   ·  Flag as inappropriate

    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.

  • Anonymous commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    Totally agree; enabling FileTables as part of SQL Azure would also enable full-text search and semantic search scenarios.

  • Ryan CrawCour commented  ·   ·  Flag as inappropriate

    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.

  • TriSys commented  ·   ·  Flag as inappropriate

    Why use a separate API for Azure storage when we can use ADO.Net and get at SQL AND file data?

Feedback and Knowledge Base