What we we comparing against?
One of the most oft-asked questions on Twitter, the RavenDB mailing list and other such methods of communication, is what are the differences between RavenDB and <insert currently preferred NoSql solution>.
The two main contenders are probably CouchDB and MongoDB – MongoDB in particular has been gathering a lot of momentum in the .NET space recently thanks to efforts such as NoRM and such.
Personally, I think that comparisons against MongoDB should stop after one question, “Is your application read or write heavy?”, comparing overall performance and functionality is completely redundant because the two pieces of software are, in my mind at least, geared for completely different scenarios. True you can create indexes to make read operations light, but then you need to make sure that your indexes fit in memory and etc etc.
I’ll stop there unless anyone complains notably, because trying to describe the differences between Couch and Mongo is a big enough task in itself, in fact you can read more about this here, and note for yourself that they really are entirely different animals.
CouchDB and RavenDB on the other hand are both geared very much towards read-heavy applications, providing up front map/reduce indexes (or materialised views) on data, scaling horizontally via replication (although Raven supports this and sharding), and they both use REST as their method of access to the data store.
There are other document databases out there, and they all do things differently, but these are the two getting the most traction from the developer eco-system that I am familiar with. Thus, I shall be comparing RavenDB against CouchDB in this series of blog entries.
So, they’re the same right?
No, not really – and to be honest I thought that aside from the major differences that RavenDB contains such as transactions, sharding, linq-based-indexes, full text search, extensibility that this was the case!
Okay, that’s a fairly big list of differences already, but the features that are additions over CouchDB are primarily candy for developer use
Disclaimer: Until last week, I hadn’t properly touched CouchDB, and it was only at a workshop ran by DevTank in London that I realised quite how different the two databases were in functionality, use and design. However – while I’m about to launch into a series of posts about this topic, I might well be wrong about a few things (due to lack of exposure), and I’ll be happy to update my blog posts and admit that I am wrong when it is pointed out to me :).
Where are we going with this?
Obviously I have next to me a massive list of differences between CouchDB and RavenDB, and it really is a big list. I’ll be splitting it out over the coming days into a series of blog entries exploring these differences in detail and giving my opinions on them.