Most Sitecore implementations that I’ve worked with are backed by SQL Server for storing the content. If you look at the database model, you will see that it is quite simple. It is designed around the key principles of the CMS itself (items and field values), rather than the data structure of the content.
This data structure is not only very simple, it also doesn’t really need any relationships besides the one between items and field values (for different languages and versions). In fact, everything comes down to just items and some data related to those particular items. A document-oriented database instead of a relational database may be a better fit!
With this in mind, I attempted to create a data provider for Sitecore that works with MongoDB. And after a few months of not working on it at all, I finally finished it in the last few evenings. Since it has not been properly tested and very likely has some major bugs still in it, I ask you to regard this as a VERY experimental implementation.
Nevertheless, I encourage anyone who is interested to play around with the module that I’ve shared on the Sitecore Shared Source website. You can find the MongoDBDataProvider here.
Setting up the module
Here are some easy steps to get started with the MongoDB data provider.
- Install MongoDB on your local machine and start it (no need to create a database)
- Get the latest source code from
SVNGitHub - Build the project
- Copy the dll and dependencies (MongoDB.Bson and MongoDB.Driver) to the bin folder in your Sitecore site
- Copy MongoDataProvider.config to your App_Config/Include folder
- Copy Transfer.aspx and TestDataProvider.aspx to your website
- Open Transfer.aspx in your browser and select the database you want to copy into MongoDB
- Open the Sitecore desktop and open the mongodb database to see if everything is working correctly
After setting things up, you can also change the database that your website works with (go to the
Measuring the speed
I’ve said it before:
In my opinion, any performance improvement (especially if it has significant drawbacks) must be proven to be worth it!
So I’ve made a page that tests the performance of any DataProvider that you select. It disregards any caching and tests several different operations a bunch of times and returns how long it took to run the operations. This might actually come in handy if you want to check your own custom made DataProvider.
Go to TestDataProvider.aspx and select the SQL Server data provider and the MongoDB data provider if you want to check the performance gain on your machine. My results are as follows:
| Operation | Duration (in milliseconds) – SQL | Duration (in milliseconds) – MongoDB with safe mode ON | Duration (in milliseconds) – MongoDB with safe mode OFF |
| Create | 3723 | 1057 | 776 |
| Add versions | 5333 | 2750 | 2181 |
| Change some field values | 7005 | 1325 | 1092 |
| Get parent id’s | 2075 | 318 | 328 |
| Get child id’s | 901 | 275 | 279 |
| Get item definitions | 2026 | 351 | 348 |
| Get item versions | 2051 | 693 | 676 |
| Get field values | 1986 | 656 | 678 |
| Delete | 9379 | 372 | 44 |
| Total | 34479 | 7798 | 6401 |
Note that the safe mode in MongoDB makes writing to the database more reliable, and also a little slower (you can find a setting for this in MongoDataProvider.config). Turning the safe mode off might be interesting on content delivery environments, because that’s where the performance really matters and you can always re-publish something if you need to (though it would be very annoying if this would be needed).
Here’s a chart with the results:
This may seem very impressive, but keep in mind that these results do NOT necessarily translate into similar improvements in speed for your entire website. A few things to keep in mind:
- Both the MongoDB data provider and this speed measurement tool have just been developed and have not had a chance to mature. Both are very likely to have serious bugs and may disregard some matters that definitely should be regarded. I’d be happy to hear from you if you would like to point out some of the things I have missed.
- Sitecore relies heavily on caching on different levels. That’s why a site (or an individual page) may be very slow only on the first request. Perhaps if your content editors publish content very often and the cache needs to be cleared on each publish, it may be a good idea to look for a faster data provider such as this module.
- The SQL Server data provider has some internal caching that I’m not sure the MongoDB data provider is exactly on par with. That means that the MongoDB data provider might actually be slower than the SQL Server data provider in a ‘real world scenario’.
Anyway, it’s been great fun trying this different approach to storing Sitecore data and I hope you enjoyed reading about it!