Filesystem verse Database Storage

Hi everyone,

Can someone please provide a detailed comparison of benefits when it comes to deciding whether or not an image should be stored in the database or filesystem? I understand the different between the two in regards to 'location', but I do not understand how to distinguish the choice of when to use what. 

We do a lot of 'web pushes' (server restarts) to move code from our test server to the live server. Will the storage location of images impact this process?

Any  help in understanding would be beneficial. 

Thank you.

Hi John

If you store your images on the file system then you save database space and access to the images for browsers is faster because they do not need to be retrieved from the database tables.

Downsides
If you backup your database you are not backing up all the images.

If you want a copy of your database for some testing or work you also need to grab a copy of the images on the disk.

The images are all named by a GUID so there is a direct relationship between the file name and the reference in the database. (So don't think you can add images directly and definitely don't rename them. You should just leave it all up to Sitefinity) But you do have to consider that the file system is now, in effect, an extension to your database  and so you should treat it that way.

I don't think pushing new code will make a difference in regards to where your images are located but I couldn't say for sure as I don't know what your code looks like.

Dude, use filesystem...your db backups will be smaller, and if you have to attach a backup to a ticket again, smaller....

 I have a project that uses db mostly because filesystem wasn't an option back then...its 2.6 gigs right now!

 ...also fs storage is cheaper than sql

Dear John

I do use database storage only for very small sites that I know are not going to have many images. 
As Darrin and Steve pointed out. The main advantage of storing in DB is having all in one place which of course if you have lots of images make it a disadvantage.

I often keep design elements in database and customer images on file system. 
Remember that if you store images on file system you need to down/upload them when you move sites. 
And as Darring pointed out they are all GUID named on file system so you have no change to know which image is which (you can add .jpg local to see what they are).

So for me often a mix is what I do to get the best of both worlds.

Markus

Reading this makes me think I want to switch to filesystem, however, like Steve's comment, it wasn't an option back when we started the site.

If I switch now to filesystem instead of database, is there a way to migrate everything out of the database and into the filesystem?

Dear Amanda

 I think out of the box you might have to set the default storage to file system - Administration - Settings (Basic) - Storage providers.

And as far I know you need to move the libraries than one by one. 

Content - Images- Action - Move to another storage.

Markus

Thanks. Do you know if this deletes them from the database or if it simply makes a copy to filesystem and starts using that instead?

Another possible reason for using the file system... if you are hosting (particularly on lower-end services) then typically you will have a tight limit on your db size, but more file space than you can use.

I found out recently that video and audio files need to be stored on the file system in order for seeking (rewind/forward/skip) to work

Hi all,

@David
Thank you for sharing this with our community. I have forwarded this information to our documentation team and I hope that it will be added in our documentation soon.

Regards,
Kaloyan
Telerik