Store pictures as files or in the database like MSSQL for a web app?

Store the pictures on the file system and picture locations in the database.

Why? Because...

1. You will be able to serve the pictures as static files.
2. No database access or application code will be required to fetch the pictures.
3. The images could be served from a different server to improve performance.
4. It will reduce database bottleneck.
5. The database ultimately stores its data on the file system.
6. Images can be easily cached when stored on the file system.

In my recently developed projects, I stored images (and all kinds of binary documents) as image columns in database tables.

The advantage of having files stored in the database is obviously that you do not end up with unreferenced files on the harddisk if a record is deleted, since synchronization between database (= meta data) and harddisk (= file storage) is not built-in and has to be programmed manually.

Using today's technology, I suggest you store images in SQL Server 2008 FILESTREAM columns (at least that's what I am going to do with my next project), since they combine the advantage of storing data in database AND having large binaries in separate files (at least according to advertising ;) )

The adage has always been "Files in the filesystem, file metadata in the database"

Better to store files as files. Different databses handle Blob data differently, so if you have to migrate your back end you might get into trouble.

When serving the impages an < img src= to a file that already exists on the server is likely to be quicker than making a temporary file from the database field and pointing the < img tag to that.

I found this answer from googling your question and reading the comments at http://databases.aspfaq.com/database/should-i-store-images-in-the-database-or-the-filesystem.html

i usually like to have binary files in the database because :

• data integrity : no unreferenced file, no path in the db without any file associated
• data consistency : take a database dump and that's all. no "O i forgot to targz this data directory."

Storing images in the database adds a DB overhead to serve single images and makes it hard to offload to alternate storage (S3, Akami) if you grow to that level. Storing them in the database makes it much easier to move your app to a different server since it's only the DB that needs to move now.

Storing images on the disk makes it easy to offload to alternate storage, makes images static elements so you don't have to mess about with HTTP headers in your web app to make the images cacheable. The downside is if you ever move your app to a different server you need to remember to move the images too; something that's easily forgotten.

For web based applications, you're going to get better performance out of using the file system for storing your images. Doing so will allow you to easily implement caching of the images at multiple levels within your application. There are some advantages to storing images in a database, but most of the time those advantages come with client based applications.

Just to add some more to the already good answers so far. You can still get the benefits of caching from both the web level maybe and the database level if you go the route keeping you images in the database.

I think for the database you can achieve this by how you store the images with relation to the textual data associated with them and if you can the access to the images into a particular query so that the database can cache the query (just theory though so feel free to nuke me on that part).

With the web side, I would guess since you're question is tagged up with asp.net that you would go the route of using a http handler to serve up the images. Then you have all the benefits of the framework at your disposal and you can keep you domain logic cleaner with only having to pass the key to your image to the http handler.