Storing Sitecore Media in the Database vs. the File System

As with all things Sitecore, the location and technique to store media assets is customizable. By default, Sitecore solutions store media assets in binary format in the database. An alternative to the database is on the actual file system. This article is an attempt to cover the pros and cons of each approach and intends to propose scenarios where each solution works best.

Storing Media Assets in the Database

As I already mentioned, by default a Sitecore solution will store media assets in the database. This is convenient since all Sitecore items in the tree are already stored in the database. This follows suit with the standard of how Sitecore is built. Though this might be the default behavior, its not always the best option. What if you want to serve images from a different domain, possibly a sub-domain that is optimized for static assets? Also, storing BLOBs in the database causes the database to increase in size, which can be problematic for database backups, restores, moves, and maintenance – do you want that burden?

Pros of Database Storage

  • No extra reliance (besides the database itself) on actual files when moving or syncing environments of a site (e.g. content management, content delivery, QA, dev)
  • The Sitecore ASHX handler to render files takes in query string parameters to dynamically re-size images

Cons of Database Storage

  • Media assets are handled and rendered through the Sitecore ASHX handler which can hide the true file type and causes .NET to process the files
  • Database sizes are increased as media assets are stored in binary right in the database – sizes for media are also increased within the database due to encoding

Settings for Database Storage

By default a Sitecore site will have the file storage setting set to false:

<setting name="Media.UploadAsFiles" value="false">

Storing Media Assets on the File System

Storing media assets on the file system has its own advantages in certain situations. This is typically a good option if you need to have actual physical files replicated to be stored elsewhere, say on a CDN such as Akamai or Limelight. For example, if you want to offload your static assets such as content-managed images, you can store them on the file system and write some code to FTP them to a CDN. This is really only possible with actual physical files.

Pros of File System Storage

  • Databases are more lean because they don’t contain any binary media data
  • Allows for files to be pushed out to a CDN (like Akamai, Limelight) with custom coding
  • You can directly change assets on the file system if you have access to it (like a developer)

Cons of File System Storage

  • When Sitecore creates physical media files, it adds the media item’s GUID to the name, so changing an asset in the media library will result in an additional file on the file system
  • It’s much more difficult to sync up environments since the actual folders on the file system need to get synced (e.g. 2 content delivery servers) – either a sync tool or the staging module can help with this

Settings for File System Storage

To set media assets to be stored on the file system, set the UploadAsFiles setting to true:

<setting name="Media.UploadAsFiles" value="true">

You can also optionally define the actual file system path where the assets are stored. By default they’re set to /App_Data/MediaFiles:

<setting name="Media.FileFolder" value="/App_Data/MediaFiles">

Additional Resources

Hopefully you now have a better understanding of the pros and cons of each approach. Below is a list of additional resources that can help you make any decisions relating to media storage.


Mark Ursino

Mark is Sr. Director at Rightpoint and a Sitecore MVP.


12 thoughts on “Storing Sitecore Media in the Database vs. the File System

  1. Great article! Thanks for taking time to write this article and discuss pros & cons of storing images in database and filesystem.

  2. A few notes:
    1. Sitecore processes both file and db based media via ASHX allowing dynamic resizing, etc.
    2. CDNs work great with db based media, you don’t have to push. Akamai will pull ASHX resource.

    I would say that db based approach is preferred especially since vet 6.

    It is obviously not a good idea to put 500 MB videos in ML – but it works great for fairly large files.

    File based media is a pain to sync as you said, so I’d say use file based only when you requirements absolutely dictate this.

  3. Thanks for the good notes Alex, you bring up a good point about CDNs. I neglected to expand on the different scenarios in which a CDN can be used. You’re absolutely right when you say files stored on the file system OR stored in the DB and served via the ASHX can get cached by the CDN. Something like Akamai Web Accelerator does that, where you supply certain file extensions to cache and various TTLs for those caches, like cache .css for 7 days and cache .jpg and .ashx for 1 day. The particular scenario I was talking about was using a CDN service as an actual hosting volume for images, meaning physically moving the files via FTP on publish. On a large project we used Akamai NetStorage to store media assets and this required physically moving the files to the Akamai server via FTP for hosting. To do this we moved media assets to the file system and had a sync tool watching the folder where the physical files were placed, and thus it would push them to Akamai. We were only able to do this with files on the file system so the sync tool could watch the folder and FTP the assets. This was a special case though, and I would agree that DB storage is much easier to manage if you can stick to it (which is most cases).

  4. “It’s much more difficult to sync up environments since the actual folders on the file system need to get synced (e.g. 2 content delivery servers) – either a sync tool or the staging module can help with this.”

    Could you please explain a little as to how staging module can be used to sync the files between 2 servers?

  5. Can you comment on or incorporate how we should understand this setting? “Media.DisableFileMedia” Thank you!

Leave a Reply

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.