This raises an age old question which will likely be debated for many years to come. Ultimately both methods of storage have their benefits and costs.
Storing images on the file system has a marginally faster retrieval rate, thanks to web and proxy servers being good at what they do.
Storing images in a database allows for all of your data to be central stored which is more portable, and easy to replicate. This solution would likely also be easier for taking a point-in-time backup with referential integrity.
Which option you choose would really depend on the type application you’re building in my opinion.
So if you’re building an application with a moderately sized amount of image data, and moderate amount of traffic using a database would be okay as the benefits outway the cost. However if you’re building something like flickr with large amounts of data and high traffic, using the file system would be the advised approach.
I’ve also heard of a combined solution that could provide the best of both world. This is storing your images in the database to gain the benefits there, but also use filesystem caching of these to obtain the performance benefits.
For a senario of a small photo storage site with 2 Gig of images, I would recommend the filesystem approach or consider attempting the combined solution. Although at only 2 Gig either approach would be fine… but we need to allow for some growth, it could boom right?
Some tips for getting the best performance out of the filesystem:
- Limit the number of images in any one directory (or suffer performance loss)
- Include not only an image identifier in the filename, but also a secret code (to prevent discovering files)
See the following website has some great information on flickr:
Additionally there is this presentation on scalable web architechure: