Storing Sitecore Media Assets - Database or File System

There are two options when it comes to storing Sitecore Media assets: store them in the Database or the File System. Sitecore recommends putting the media assets in the database rather than on the file system, to take advantage of the CMS functionality and be able to move the media from master to delivery servers by publishing the relevant items. The recommendation is not ideal for all scenarios. In sites where the number of images is small, this is fine.  However, in scenarios where the number of images is large and they impact performance of site, storing on the file system and being rendered by the webserver directly is better option.

The advantages of having the images in the database are:

1. No need to handle as the assets are not on the file system, meaning publishing from Sitecore Master Server will automatically move those assets to Sitecore Delivery Servers. This has been stated as primary disadvantage of storing assets on file system instead of in a database. However, from our perspective, this is not a huge disadvantage considering you can configure the file synchronization mechanisms using DFS or WebDeploy from master to Delivery Servers.
   
   
2. Images will be like any other items in the CMS and provide functionality applicable to media library, such as locking, security, workflow of items. This functionality is applicable at item meta-data level only when using the file system as storage mechanism. In my opinion, the media library feature set should be agnostic of the storage mechanism and provide for the feature set in either case; by taking into consideration file attributes if required. 

However, the disadvantages of storing images in the database are:

1. It can cause bloating of the databases, impacting performance. It depends primarily in the amount of assets your organization would have for the items.
             Here is a rough calculation on how this could bloat up the database: Assuming 25 KB average per image, with 4 images per product, with 25000 products will cause it to have 25000*4*25=2.5 GB just for asset storage. The increased database size causes increase in amount of space requirements. If you have a production master DB, then replicating to QA and DEV will be 6 fold, as there would (master+web) databases to be moved to QA and DEV.  This would also be backed up based on backup processes, which require more time and space for backups. This may or may not be limitation, based on the amount of hardware available to the sitecore servers, but it definitely can be optimized.
2. It will put a lot more performance overhead on the Sitecore servers (.NET process) to retrieve, cache and render these assets, which would be better handled if they were managed through webserver.

Considering the above reasons and several file system synchronizations available to provide the convenience to move assets, I consider that the trade-off of losing any CMS provided benefits (locking, security, workflow of items) of storing in the database are diminished due to the gain in performance on end site; by storing the assets on the file system. Therefore, I recommend using the file system as the storage mechanism in scenarios where there are large numbers of images, and being served by Web server for performance reasons. If the number of images is small, then storing in the database may be considered for convenience. As with any project, one should make their decision about the the storage mechanism taking into account the business requirements.