Store user profile pictures on disk or in the database?

Question

I'm building an asp.net mvc application where users can attach a picture to their profile. This picture will obviously be displayed in the profile, but other parts of the system too, like a messaging gadget on the dashboard that displays recent messages displays a little profile iconnext to the users message(s).

When the user uploads these I am wondering whether it would be better to store these in the database or on disk.

Databse advantages

• easy to backup entire database and keep profile content/images with associated profile/user tables
• when I build web services later down the track, they can just pull all the profiile related data from one spot(the database)

Filesystem advantages

• loading files from disk is probably faster
• any other advantages?

Where do other sites store this sort of information. Am I right to be a little concerned about database performance for something like this?

Maybe there would be a way to cache images pulled out from the database for a period of time?

Alternatively, what about the idea of storing these images in the database, but shadow copying them to disk so the web server can load them from there. This would seem to give both the backup and convenience of a Db, whilst giving the speed advantages of files on disk.

Infrastructure in question

• The website will be deployed to IIS on windows server 2003 running NTFS file system.
• The database will be sql server 2009

Summary

Reading around on a lot of related threads her on SO a lot of people are now trending towards the SQL Server Filestream type. From what I could gather however (I may be wrong) there isn't much benefit when the files are are quite small. Filestreaming however, greatly improves performance where files in in the multiple MB's or larger.

As my profile pictures tend to sit around ~5kb I decided to just leave them stored in a filestore in the database as varbinary(max).

In ASP.NET MVC I did see a bit of a performance issue returning FileContentResults for images pulled out of the database like this. So I ended up caching the file on disk when it is read if the location to this file is not found in my application cache.

So I guess I went for a hybrid; - Database storage to make baking up of data easier and files are linked directly to profiles - Shadow copying to disk to allow better caching

At any point I can delete the cache folder on disk, and as the images are re-requested they will be re-copied on first hit and served from the cache there after.

Answer 1

Actually your datastore look up with the database may actually be faster depending on the number of images you have, unless you are using highly optimized filesystem engine. Databases are designed for fast lookups and use a LOT more interesting techniques than a file system does.

reiserfs (obsolete) really awesome for lookups, zfs, xfs and NTFS all have fantastic hashing algorithms, linux ext4 looks promising too.

The hit on the system is not going to be any different in terms of block reads. The question is what is faster a query lookup that returns the filename (may be a hash?) which in turn is accessed using a separate open, filesend close? or just dumping the blob out?

There are several things to consider, including network hit, processing hit, distributability etc. If you store stuff in the database, then you can move it. Then again, if you store images on a content delivery service that may be WAY faster since you are not doing any network hits on yrouself.

Think about it, and remember bit of benchmarking never hurt nobody :-) so test it out with your typical dataset size and take into account things like simultaneous queries etc.

Answer 2

Store references to the files on a database and store the files themselves on disk.

This approach is way more flexible and easier to scale.

You can have a single database and several servers serving static content. It will be much trickier to have several databases doing that work.

Flickr works this way.

Hope it helps.