It has been a while since I have dealt with this, but we are in the process of converting an old Zope based site to run on a Ruby on Rails architecture. The old site stores all user profile images as blobs in the database. Going forward I was not sure if I wanted to keep this method for maintaining profile images or just keep a pointer to the image in the database and store the actual image in the filesystem. Here is what I came up with from reading, talking to friends, and recalling my long past experiences with this.

Pros

• Obviously migration to another server or creating dev/test instances become much easier.
• Offers better protection of images from leeching.
• No need for filesystem manipulation for placement and naming of images.
• Synchronizing between the database and filesystem is no longer an issue.
• Repurposing images for thumnails or other areas of the site is easier and takes less space.

Cons

• Flexibility is lost because images can only be accessed by the database.
• Migration to a different database vendor may be very messy because of different image storing standards.
• No need for filesystem manipulation for placement and naming of images.
• When dealing with large traffic, database processing to display an entire image is much slower than simply querying for a link to an image.
• You may have to create extra code in order to have some sort of image viewer since you won’t be able to use a standard fair image viewing application.
• In the event the database needs to be taken down, caching image content will be cumbersome and will impact which sections you can and can’t keep up. This is far less of any issue when using the filesystem.

In the end we went with keeping a pointer to the image location in the database and keeping the actual image in the filesystem.