Images in database vs file system

This question comes up often - see this SO search result.

There is no one right answer - it depends on circumstances.

Personally - keep a file path in the DB and the file on the filesystem. Each has its own strengths. You can backup files as well as databases. This is also the conclusion of this guy, who manages TBs of data.

Replication of static files, especially across a number of servers, can be difficult to manage. It really comes down to a tradeoff between managing, monitoring and debugging replication problems vs. the database size and load.

I think I'd probably pick the database approach, and if load became an issue look at putting up some sort of cache layer around the image calls.

Suggestions to store a path in the db are missing the real problem, which is replicating this across multiple machines.

Your concerns break down into two camps. The following concerns favour storing documents in the database:

• Data integrity
• Data replication
• Multiple resolutions
• Data management and backup

These concerns (probably) favour storing documents on the file system:

• Speed of database vs file system
• Overhead load of database vs file system

So, decide what matters the most and choose accordingly.

There are valid concerns on either side of the debate, so always give your requirements. How much data, how many images, how large?

Inline / BLOB storage

Upside: simplifies architecture and implementation, simplifies backup and recovery or migration of the system; just do a dump, backup, export (whatever the term for your flavor of DB) and move it to the new database. Version control / consistency is handled by the DB, so allows for point-in-time recovery. Security / access control is also cleaner, since access to an image BLOB is intrinsic to access to the overall row. Moving the image outside the DB and letting the HTTP server fetch it up, while better for concurrency and scalability, can have problems with ensuring people cannot hack URLs and request images they don't own. If you do house them outside the DB, make sure either your security policy covers access control of images between users. Either your HTTP server authentication has to integrate with the overall system's authentication, or your HTTP server program that serves up the images uses some sort of session mechanism to ensure the HTTP request is valid. This is a very big concern in multi-tenant databases. Less of a concern in single purpose, single-tenant systems, with simple authentication.

Downside: For really REALLY large databases, the backup and recovery gets frustrating, or even problematic and costly, because where you may have a small core dataset otherwise, you may have many GB or TB of image data. Treating it all as one consistent database is both good from integrity point of view, but bad for backups unless you use DBMSes with enterprise quality, data warehouse tuned backup and recovery (example is Oracle RMAN and rolling backups).

Always consider time to recovery in any system. If your storage requirements are < a few gigabytes, say 50-100GB even, and you have plenty of backup space planned, inline stor