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

Question

My question is fairly generic and I know there might not be an 100% answer to it. I'm building an ASP .NET web solution that will include a lot of pictures and hopefully a fair amount of traffic. I do really want to achieve performance.

Should I save the pictures in the Database or on the File system? And regardless the answer I'm more interested in why choosing a specific way.

Many thanks, Stefan

DUPLICATE: Storing Images in DB - Yea or Nay?, How to store images in your filesystem, Storing a small number of images: blob or fs? and probably some others.

---

COMMENT: Thanks for many good answers. I will go for a file based solution even if I like the idea of having a 100% database driven solution. It seems that there are today good solutions to do what I want with databases etc but I have a few reasons for not doing it.

• I will be on a hosted solution, I have huge amount of storage(10gb) but only 300mb for the database. It will cost a lot for extra storage in the DB.

• I'm not an DB expert and as well not in control of settings of the DB. A DB based solution might need custom configuration as it looks like.

If we will move to run the site on our own server I might consider a DB based solution. thanks, Stefan

Answer 1

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

Answer 2

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 ;) )

Answer 3

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.

Answer 4

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.

Answer 5

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

Answer 6

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."

Answer 7

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.

Answer 8

Hi,

I'm talking from my own experience. Actually, I was working on the same matter today. We have a database that stores Binary Assets.

It has it advantages and disadvantages. One big disadvantage is that the database will get very large. The good thing about is that you can use hashing to see if a "blob" is allready in the system or not.

This way we can easely search for an image. But it's true what "Akbar ibrahim" says, you can do a lot with images if they are stored in a folder. But about the caching, we've found a solution for that. We have a page that is called, RetrieveBlob.aspx. This will fetch the image/sound/video from the database and send it to the client. If you add this part to the web.config you will use caching as well:

<caching>
  <outputCache enableOutputCache="true" />
  <outputCacheSettings>
   <outputCacheProfiles>
    <add duration="180" enabled="true" varyByParam="*" name="AssetCacheProfile" />
   </outputCacheProfiles>
  </outputCacheSettings>
 </caching>

In the page you add the following:

<%@ OutputCache CacheProfile="AssetCacheProfile" %>
<%@ Page Language="C#" AutoEventWireup="true" CodeFile="RetrieveBlob.aspx.cs" Inherits="RetrieveBlob"  %>

I could give you more information if you like.

Regards, Sem

Answer 9

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.