Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,125 | Comments: 45,492

filter by tags archive

RavenDB in comparison to CouchDB

time to read 5 min | 839 words

I run into this question, and I thought that this is an important enough topic to put it on the blog as well.

A cursory dig suggests CouchDB is more mature, with a larger community to support it. That aside, what do you consider to be the significant differences?

RavenDB was heavily inspired by CouchDB. But when I sat down to build it, I tried to find all the places where you would have friction in using CouchDB and eliminating them, as well as try to build a product that would be a natural fit to the .NET ecosystem. That isn't just being able to run easily on Windows, btw. It is about being a product that fits the thought processes, requirements and environment in which it is used.

Here are some of the things that distinguish RavenDB:

  • Transactions - support for single document, document batch, multi request, multi node transactions. Include support for DTC. To my knowledge, CouchDB supports transaction only on a single document.
  • Patching - you can perform a PATCH op against a document, instead of having to send the entire document to the server.
  • Set based operations - basically, a way to do things like: "update active = false where last_login < '2010-10-01'"
  • Deployment options - can run embedded, separate executable, windows service, iis, windows azure.
  • Client API - comes with a client API for .NET that is very mature. Supports things like unit of work, change tracking, etc.
  • Safe by default - both the server and the client have builtin limits (overrdable) that prevent you from doing things that will kill your app.
  • Queries - Support the following querying options:
    • Indexes - similar to couch's views. Define by specifying a linq query.
    • Just do a search - doesn't have to have an index. RavenDB will analyze the query and create a temporary index for you. However, unlike couch temp views. This is meant for production use. And those temp indexes will automatically become permanent ones based on usage. Note that you don't have to define anything, just issue the actual query: Name:ayende will give you back the correct result. Tags,Name:raven will also do the same, including when you have to deal with extracting information directly from the composite docs.
    • Run a linq query - this is similar to the way temp view works, it is an O(n) operation, but it allows you to do whatever you want with the full power of linq. (For the non .NET guys, it allows you to run a SQL query against the data store) Mostly meant for testing.
  • Index backing store - Raven puts the index information in Lucene, which means we get full text searching OOTB. We can also do spatial queries OOTB.
  • Searching - It is very easy to say "index users by first name and last name", then search for them by either one. (As I understand it, I would have to define two separate views in couch for this).
  • Scaling - Raven comes with replication builtin, including master/master. Sharding is natively supported by the client API and requires you to simply define your sharding strategy.
  • Authorization - Raven has an auth system that allows defining queries based on user / role on document, set of documents (based on the doc data) and globally. You can define something like: "Only Senior Engineers can Support Strategic Clients"
  • Triggers - Raven gives you the option to register triggers that will run on document PUT/READ/DELETE/INDEX
  • Extensibility - Raven is intended to be customized by the user for typical deployment. That mean that you would typically have some sort of customization, such as triggers, additional operations that the DB can do.
  • Includes  & Live projections -  Let us say that we have the following set of documents: { "name": "ayende", "partner": "docs/123" }, { "name": "arava" }
    • Includes means that you can load the "ayende" document, while asking RavenDB to load the document referred to by the partner property. That means that you have only a single request to make, vs. 2 of them without this feature.
    • Live projections means that we can ask for the document name and the name of the partner's name. Effectively joining the two together.
    • Those two features will only work on local data, obviously.

And I am probably forgetting some stuff, to be honest. Oh, and I am naturally the most unbiased of observers :-)


Bogdan Marian

@Ayende - Out of the curiosity, were you the only one developer for RavenDB or there were others to help you ?

Ayende Rahien


There are currently 27 people who committed to RavenDB, but I am the major committer.


The link is to an archive, not a specific question.


Curious, whats the different between MongoDB vs CouchDB/RavenDB? Isn't MongoDB more popular than CouchDB?


So based on google, MongoDB is geared more towards writing while CouchDB/RavenDB is geared more towards reading.?

Matt Warren


I don't know about the others, but in RavenDB it's true that "reads are cheap and writes are expensive (relatively)".

Rob Ashton

I always thought of it as "reads are cheap and writes are cheap, but you might have to wait for consistency"

Whereas Mongo is fast writes, slow reads, couch is slow writes fast reads but both are consisrent-at-point-of-query

Plus everything else that is different.

Ayende Rahien


Well, writes are cheap, but they still go to disk.

Mongo make them very cheap because they write to memory

Rob Ashton

Details :-)

I guess relative to some of the other solutions raven-fast could be considered as slow, but compared to say a relational store where we have indexes and foreign keys set up and a write means validating all of these?

Doesn't it depends what we are comparing against?

Demis Bellot

What exactly do you mean by writes are cheap and reads are cheap?

Doesn't the fact that its writing to disk make it expensive?

What exactly are you comparing them to? Since you're saying they're both cheap you're not talking about RavenDB's reads vs writes - how can they both be cheap?

Without a point of reference this just sounds like marketing speak.

Comment preview

Comments have been closed on this topic.


  1. RavenDB 3.5 Whirlwind tour: I need to be free to explore my data - 7 hours from now
  2. RavenDB 3.5 whirl wind tour: I'll have the 3+1 goodies to go, please - 3 days from now
  3. The design of RavenDB 4.0: Voron has a one track mind - 4 days from now
  4. RavenDB 3.5 whirl wind tour: Digging deep into the internals - 5 days from now
  5. The design of RavenDB 4.0: Separation of indexes and documents - 6 days from now

And 11 more posts are pending...

There are posts all the way to May 30, 2016


  1. The design of RavenDB 4.0 (14):
    05 May 2016 - Physically segregating collections
  2. RavenDB 3.5 whirl wind tour (14):
    04 May 2016 - I’ll find who is taking my I/O bandwidth and they SHALL pay
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats