Skip to content

John Bennett's blog

Why we looked at RavenDB

Tuesday, March 6, 2012

In my previous post, I talked about our initial work in our new “SkyPad” CMS, and some of the tradeoffs we made around data storage and replication.

As we continued to evolve SkyPad, we realized that the majority of our data isn’t inherently relational.  It’s almost entirely documents — serialized object blobs.  That caused us to look at the available options for key-value stores, document stores, distributed hashtables and the like.

RavenDB looked like a good fit for a bunch of reasons:

It is a document database. The basic paradigm is fairly close to our problem domain: saving, updating and publishing documents.  Our editors, developers and admins think and talk in terms of documents.

It is schema-less. To keep up with our competition and with what our users expect, we have to be adding and changing features constantly.  We need to add properties to our entities, create new entities, split entities, rename entities.  RavenDB stores documents as JSON.  It de/serializes our types effortlessly, while giving us the tools to take over and do our own thing when necessary.  There is no schema to keep in sync with our code changes.

It is transactional. We can’t afford to lose a document.  If our database says “I saved it”, we need that to be true no matter what.  Our service bus is built with WCF and MSMQ.  RavenDB works with System.Transactions as you would expect, so we didn’t have to do anything special to use it during transactional message handling.

It is .NET-focused and supports querying with Linq. We’re a .NET shop.  Ramp-up speed for new developers and code readability are critical.  Anyone who has used C# and Linq can understand the queries we’re making against RavenDB and start creating their own very quickly.  Not to mention we can all read the RavenDB source itself more easily.

It is extensible. The list of provided bundles reads almost like our requirements list:  replication, versioning, document expiration, authorization.  Plus we can change RavenDB’s behavior where we need to.  (Bundles on the server side, and listeners on the client-side.)  That makes our developers a lot more comfortable.

It is both open source and commercial. We can see all the code, submit pull requests when we want something to be different, or just make our own private changes to the codebase.  But we can also pay for it, count on support, and — ahem — have a throat to squeeze if something goes seriously awry…

It is based on very mature storage technology. RavenDB writes everything to disk, and the underlying storage is ESENT, which is also used by Exchange and Active Directory.  Those underpinnings made our Ops team more comfortable trying it out.  We have a humongous read-write ratio, so the performance characteristics of writing everything to disk are just fine for us.