Yes, You are correct.

https://world.episerver.com/blogs/Per-Magne-Skuseth/Dates/2014/4/SQL-Blob-Provider-Store-your-blobs-in-the-database/

Thank you Ravindra

Hi,

Is there a specific reason you want to store the blobs in the database? 

The reason that has been before is that I find it much easier to copy data from one environment to another. Backup and restore to the desired environment database and its done.

But now when its Azure maybe thats not the case anymore.

Is there a specific reason to use Azure-blobs?

Regards Hans

Performance is probably much better with Blob storage. I have no numbers to back this up though :) But SQL is not really designed for blobs.

You also get much more data to move around when everything is stored in the DB. I guess this could also make deploys slower.

But if you want to move the blobs to another environment, will not that take time?

Lets say you get your integration environment filled with content thats correct. And you want to move that to preproduction and later production.

We have to move the database content and we have to move the azure-blobs. Is that faster than moving a database with blobs?

Is there an easy way to move the Azure-blobs from integration to, lets say, preproduction?

And if performance is better with Azure blobs thats good. Then it does not matter if moving data takes longer, because that is not what you do every day.

Hope you understand what I mean.

/Hans

I just want to note that this is not officially tested on DXC so there is no guarantee that it will work properly. It might, but if you run into problems you will have difficult time getting support. 

For moving content between environments I would recommend using the export/import funcationality instead.

I typically just backstage the DB and not all blobs if I need the production data locally for debugging purposes. Then it's less data to move. But you are correct, it's still the same amount of data to move if you want to include the blobs.

@Quan Mai

Just to be sure. Do you mean that the SqlBlobProvider is not officially tested?

/Hans

@Johan Petersson

The old site, we now are building a new one for, we started up with the built in blobprovider. This was before, hosting inhouse. I just remember that if you wanted both database-data and files copied from production to lets say, stage. It took a really long time to copy the files over the network, especially when there are a lot of files. Having the blobs in the database for that reason I found much easier. But as I said, its not often you do that. And if you want to make another environment identical regarding data I dont find export/import an easy solution.

If Azure-blobs are faster I will probably go for that.

Thanks

Regards Hans

As far as I know - of course I can be wrong here - SqlBlobProvider was not tested by Episerver QAs on DXC. 

Ok, thanks a lot everyone for your help

Regards Hans

@Hans sorry for jumping in late on this thread. I agree with @Johan's points. And I have some additional tips/points.

In our local Development environments, our Devs use a separate Container but still inside the same DXC Azure Blob storage used for Integration.

This means on your Local environment the Connection String is the same as Integration, but in the Blob provider config, we set a different Container name (think Folders). You can decide if your Developers share the same Blob Container (we have done this quite successfully), or you each Developer has their own Container.

<blob defaultProvider="azureblobs">
  <providers>
    <add name="azureblobs" type="EPiServer.Azure.Blobs.AzureBlobProvider,EPiServer.Azure" 
    connectionStringName="EPiServerAzureBlobs" container="development-local" />
  </providers>
</blob>

Then we use a Config Transform to set it back to the Integration Environment Container

<blob defaultProvider="azureblobs" xdt:Transform="Remove" />
<blob defaultProvider="azureblobs" xdt:Transform="Insert">
  <providers>
    <add name="azureblobs" type="EPiServer.Azure.Blobs.AzureBlobProvider,EPiServer.Azure" 
    connectionStringName="EPiServerAzureBlobs" container="mysitemedia"/>
  </providers>
</blob>

I'd also add that when moving between environments, while Blobs in the DB is simpler, it also means your Blobs and DB data are coupled together.

Restoring DBs up from Integration -> Pre-production -> Production is really only an option until Production is live, after that you'll use Export/Import. But over time you will likely want to refresh your lower environments from Prod (and most of the time you'll want to include the Blobs), but sometimes you'll just want a bacpac (backup) of Production DB for local debugging. 

For these reasons, plus the possible performance benefits of Azure Blobs vs SQL, I think decoupling the DB from Blobs makes the most sense.

Thank you for the tip Darren

/Hans