Why Raven DB?

However as a pragmatic developer, I am wondering what new this project is offering in a saturated market where you have quite mature alternatives like CouchDB, MongoDB, Tokyo, Redis, and many more ?
Many of these products are also cross platform and run at C speed with a proven record, being used in very big web sites where their sharding capabilities and fault tolerance have been pushed far.

The answer is composed of several parts, and cover quite a bit of history.

Why Raven DB from Ayende’s point of view?

Almost two years ago, I decided that it is time that I give my Erlang reading abilities a big push and sat down and read Couch DB source code. That was quite interesting, and was one of the reasons that I got interested in that NoSQL Thing. Unfortunately, I am one of those people who have a really hard time learning by osmosis, I have to do something to truly understand it. I have used (and built) a distributed key value store in several projects, but I felt that I didn’t really have a good understanding on what it means to use a document database.

I really hate having ideas stuck in my head, they tend to ping and then someone tell me that I have been staring at a blank wall for two hours, and I realize that I just finished designing a document database. And about a year ago, it finally got bad enough that I sat down and wrote an implementation, just to get it off my chest. That was Rhino DivanDB. In most ways, it was a proof of concept, more than anything else. Just enough so I could tell myself, yes, I can do it.

Then I run into situations where a document database would be an ideal fit, except… that the available choices wouldn’t quite do what I wanted. They are all open source, however, so no problem there, right? Except that none of them are really approachable to the .NET eco system. Yes, I can do both C++ and Erlang, but I don’t really like it. Moreover, it seems like .NET support is almost an afterthought (if at all) for those projects.

There are some people who call me arrogant, but I really do think that I can do better. And I think that we did. Raven is a project where I tried a lot of new things, not from coding perspective, but from community & launch perspectives. It will be out soon, and I think you’ll be able to appreciate the level of focus on the non coding aspects of the project.

Why Raven DB from your point of view?

Raven is an OSS (with a commercial option) document database for the .NET/Windows platform. While there are other document databases around, such as CouchDB or MongoDB, there really isn’t anything that a .NET developer can pick up and use without a significant amount of friction. Those projects are excellent in what they do, but they aren’t targeting the .NET ecosystem.

Raven does, and in so doing, it brings a lot of benefits to the table. When building Raven and the supporting infrastructure, the focus was always on making sure that it did the Right Thing from the .NET developer point of view. Below you can see a more detailed analysis on Raven’s benefits, but it comes down to that. Raven is build by .NET developers for .NET developers.

Corny, isn’t it? But true nonetheless.

What does Raven DB has to offer? Raven…

• builds on existing infrastructure that is known to scale to amazing sizes (Raven’s storage can handle up to 16 terrabytes on a single machine).
• runs, natively and with no effort, on Windows. In comparison, to get CouchDB to run on Windows you start by compiling Erlang from source.
• is not just a server. You can easily (trivially) embed Raven inside your application.
• is transactional. That means ACID, if you put data in it, that data is going to stay there.
• supports System.Transactions and can take part in distributed transactions.
• allows you to define indexes using Linq queries.
• supports map/reduce operations on top of your documents using Linq.
• comes with a fully functional .NET client API, which implements Unit of Work, change tracking, read and write optimizations, and a bunch more.
• has an amazing web interface allowing you to see, manipulate and query your documents.
• is REST based, so you can access it via the java script API directly.
• can be extended by writing MEF plugins.
• has trigger support that allow you to do some really nifty things, like document merges, auditing, versioning and authorization.
• supports partial document updates, so you don’t have to send full documents over the wire.
• supports sharding out of the box.
• is available in both OSS and commercial modes.

There are probably other things, but I need to head out for a client now, so I’ll stop.

I would love to hear your opinions about it, both positive and negative.