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:

[csharp]
<setting name="Media.UploadAsFiles" value="false">
[/csharp]

…

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:

[csharp]
<setting name="Media.UploadAsFiles" value="true">
[/csharp]

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

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

…

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.

• MediaConversionTool – A module to convert assets from database to file system and vice versa
• Tips to create a dedicated image server for Sitecore: part 1 and part 2
• Using cookie-free domains for static assets for better performance
• Configure ETags for performance gains
• Sitecore Media Facilities documentation [PDF link]
• Notify a CDN or (anything else) about the items processed from a publishing operation