Question

Using Rails, is there a reason why I should store attachments (could be a file of any time), in the filesystem instead of in the database? The database seems simpler to me, no need to worry about filesystem paths, structure, etc., you just look in your blob field. But most people seem to use the filesystem that it leaves me guessing that there must be some benefits to doing so that I’m not getting, or some disadvantages to using the database for such storage. (In this case, I’m using postgres).

Answer 1

This is a pretty standard design question, and there isn’t really a ‘one true answer’.

The rule of thumb I typically follow is ‘data goes in databases, files go in files’.

Some of the considerations to keep in mind:

1. If a file is stored in the database, how are you going to serve it out via http? Remember, you need to set the content type, filename, etc. If it’s a file on the filesystem, the web server takes care of all that stuff for you. Very quickly and efficiently (perhaps even in kernel space), no interpreted code needed.

2. Files are typically big. Big databases are certainly viable, but they are slow and inconvenient to back up etc. Why make your database huge when you don’t have to?

3. Much like 2., it’s really easy to copy files to multiple machines. Say you’re running a cluster, you can just periodically rsync the filesystem from your master machine to your slaves and use standard static http serving. Obviously databases can be clustered as well, it’s just not necessarily as intuitive.

4. On the flip side of 3, if you’re already clustering your database, then having to deal with clustered files in addition is administrative complexity. This would be a reason to consider storing files in the DB, I’d say.

5. Blob data in databases is typically opaque. You can’t filter it, sort by it, or group by it. That lessens the value of storing it in the database.

6. On the flip side, databases understand concurrency. You can use your standard model of transaction isolation to ensure that two clients don’t try to edit the same file at the same time. This might be nice. Not to say you couldn’t use lockfiles, but now you’ve got two things to understand instead of one.

7. Accessibility. Files in a filesystem can be opened with regular tools. Vi, Photoshop, Word, whatever you need. This can be convenient. How are you gonna open that word document out of a blob field?

8. Permissions. Filesystems have permissions, and they can be a pain in the rear. Conversely, they might be useful to your application. Permissions will really bite you if you’re taking advantage of 7, because it’s almost guaranteed that your web server runs with different permissions than your applications.

9. Cacheing (from sarah mei below). This plays into the http question above on the client side (are you going to remember to set lifetimes correctly?). On the server side files on a filesystem are a very well-understood and optimized access pattern. Large blob fields may or may not be optimized well by your database, and you’re almost guaranteed to have an additional network trip from the database to the web server as well.

In short, people tend to use filesystems for files because they support file-like idioms the best. There’s no reason you have to do it though, and filesystems are becoming more and more like databases so it wouldn’t surprise me at all to see a complete convergence eventually.