Storing a small number of images: blob or fs?

Question

I'm adding some functionality to my site so that users can upload their own profile pictures, so I was wondering about whether to store them in the database as a BLOB, or put them in the file system.

I found a question similar to this here: Storing images in DB: Yea or Nay, but the answers given were geared more towards people expecting many many thousands or even millions of images, whereas I'm more concerned about small images (JPEGs up to maybe 150x150 pixels), and small numbers of them: perhaps up to one or two thousand.

What are the feelings about DB BLOB vs Filesystem for this scenario? How do clients go with caching images from the DB vs from the filesystem?

If BLOBs stored in the DB are the way to go - is there anything I should know about where to store them? Since I imagine that a majority of my users won't be uploading a picture, should I create a user_pics table to (outer) join to the regular users table when needed?

---

Edit: I'm reopening this question, because it's not a duplicate of those two you linked to. This question is specifically about the pros/cons of using a DB or FS for a SMALL number of images. As I said above, the other question is targeted towards people who need to store thousands upon thousands of large images.

Dumont

Answer 1

To answer parts of your question:

How do clients go with caching images from the DB vs from the filesystem?

For a database: Have a last_modified field in your database. Use the Last-Modified HTTP header so the client's browser can cache properly. Be sure to send the appropriate responses when the browser requests for an image "if newer" (can't recall what it's called; some HTTP request header).

For a filesystem: Do the same thing, but with the file's modified time.

If BLOBs stored in the DB are the way to go - is there anything I should know about where to store them? Since I imagine that a majority of my users won't be uploading a picture, should I create a user_pics table to (outer) join to the regular users table when needed?

I would put the BLOB and related metadata in its own table, with some kind of relation between it and your user table. Doing this will make it easier to optimize the table storage method for your data, makes things tidier, and leaves room for expandability (e.g. a general "files" table).

Pulpy

Answer 2

I once faced a similar question with a small DMS for pdf files. The scenario was different from yours: A maximum of may be 100 files with sizes up to 10 MB each - not what you expect for profile pictures. But the answer a friend gave me back then applies to your case as well:

Use each storage system for what it is designed to do.

Store data in a database. Store files in a file system.

This is not the ultimate answer(*), but its a good rule of thumb for starters.

I have never heard of the Windows FS being slow and sometimes unreliable, as Aaron Digulla states in his answer. If there are such problems, this certainly needs to be factored in. But for avatar pictures, it does not strike me as important.

(*) I know, I know, 42...

Traction

Answer 3

DB is optimized for latency, transactions, etc.

Image storage is optimized for read latency, storage cost, etc.

A blob store is ideal for storing millions of images. I work on SeaweedFS. It was based on Facebook's design for storing their user photos.

Query

Answer 4

What would be more convenient, from the perspective of serving them, writing the code to serve them, backup procedures, etc.? You want the right answer for you, not the right answer for someone else.

Geo

you tell me. What do you think is most convenient/most reliable/easiest/whatever? – Dumont

Answer 5

From my point of view anything what may be left outside of database should stay outside. It may be file system or separate tables which you do not replicate or backup every day. It makes database much lighter, it grows slower and it easier to understand and maintain.

If you are on MSSQL make sure that blobs are stored in separate data file. Not in PRIMARY as everything else.

Puett

If you do not replicate or back them up every day, how are you going to restore? Or do you not care so much about these files? – Kind

Answer 6

On Windows, put as much as you can in the database. The filesystem is somewhat slow and sometimes even unreliable.

On Linux, you have more options. Here, you should consider moving big files into a filesystem and just keep the name in the DB. If you use a modern filesystem like Ext3 or ReiseFS, you can even create many small files with pretty good performance.

You also need to take into account how you can access the data. If you have everything in the DB, you have one access path, need not worry about another set of permissions, but you have to deal with the extra complexity of reading/writing BLOBs. In many DBs, BLOBs can't be searched.

On the filesystem, you can run other tools on your data which isn't possible if the files are stored in a DB.

Gutenberg

Answer 7

I would store them in the database:

1. Backup/restore is easy (if you backup files and also the database, point-in-time recovery is more complicated)
2. Transactions in the db mean you should never end up pointing at a file-name that is not there
3. Less chance someone is going to figure out a sneaky way of putting a script onto your server via a dodgy image upload hack

Since you are talking about a small number of images, ease of use/administration should take preference over performance issues which are debated in the linked questions.

Kind

Answer 8

I think there is a managability advantage storing them in the database; they can be backed up and restored consistently with the other data - you won't forget to delete obsolete ones (well, you might, but it's a bit less likely), and if you migrate the database to another machine, the images go with it.

Manila