Storing blob data is where most people start. Where they end up after performance tanks is to move the blob data back to the file system which is where it really belongs.
By storing blob data within the database your database server’s hard drives have to work that much harder trying to support both the normal database traffic as well as the additional traffic of the blob data being written to disk. You also end up wasting a lot of memory on the database server while the database server tries to cache blob data into memory which is of no use as the image probably isn’t going to be called all that often. On a machine with only a couple of Gigs and even a half way busy database this could easily eat up 25-50% of your memory taking away from loading your OLTP data into memory.
There are advantages to storing blobs in the database, though – you get ACID compliance, your backup tasks are a little bit simpler, and you can use replication to duplicate the information to multiple servers.
For the best of both worlds, you can store the “master” data in the database, and use some caching system to keep the image also stored in a file. Your web server can serve the file without touching the database, and your caching system will be responsible for updating the file if it’s not found or if the master data changes. Just make sure that you don’t do SELECT * against a table containing a blob, when you don’t need that column!