Pros and Cons: Comparing RavenDB and FoundationDB

We've recently been evaluating options for storage for a new profiles micro-service. The original prototype for this was produced in Raven, but recently other teams within the business have been having some level of success with FoundationDB. While RavenDB is touted as a "Document Store", FoundationDB claims to be simply a "Key/Value pair store. Below is my assesment of the pros and cons of each.

RavenDB

---

Pro

• Excellent .NET client API with extensibility points, providing easy developer learning curve
• Designed as Document Store
• Provides Index/Map/Reduce
• Stores natively as JSON
• Good Read Performance
• Fits excellently into integration testing, due to in memory db option designed for testing
• Automatically generates Ids for records
• Well presented web based management studio
• Raven Server has a good console where you can see requests/response times and what indexes are used to resolve queries

Con

• Cannot test replication, sharding or authenticated access functions without purchasing licenses and licenses are needed for anything other than development (UAT would need licenses)
• Some concerns over the dependence of the RavenDB project on one key developer
• Some concerns about the robustness of the testing of the product and its unproven track record in enterprise solutions (posts like this are easy to find
• Yet another product for devops to support
• Need to understand the “eventually consistent” model well when designing solutions

FoundationDB

---

Pro

• We already use it in several other services (we have experience of it)
• Better licensing terms (by far) All features free outside production, and production licensing terms essentially means it is currently free for us to use
• Full ACID compliance
• Has both Consistency and Availability during Partitioning (assuming it isn’t a catastrophic failure)
• Built in transaction retries
• Support from FDB team is excellent
• Excellent read performance both single reads and range reads are only marginally slower
• Transaction isolation level is serializable
• Simple to scale horizontally

Con

• Designed as a Key/Value pair store rather than Document Store
• Weak .NET support (only 3rd party .NET client wrapper on top of C) with less .NET documentation/support. NET not considered first class citizen of FoundationDB
• Constraints on deployment - cannot be deployed in IIS, must be self-hosted - loss of IIS specific features such as graceful request handling, automatic app pool recycles/mem management
• Cannot run in multiple AppDomains on same process
• Like Raven, also an Alpha product, though we have less concerns about the composition of the development team
• Does not generate IDs, so a separate “ID Generation Service” would be required (or switch entire platform to GUIDs with the resulting data migrations
• No nice ‘management’ interface - you need to roll your own admin tool

To summarise the differences at high level I would say that RavenDB is great for .NET developers to rapidly write applications against, but may provide a problematic operational experience, and paying before you can test replication/"clustering" successfully is a tough ask. Conversely, FoundationDB has a really steep curve to get going with .NET, you have to live without several normally expected comforts, but does provide a compelling operational case from the ACID/clustering point of view (though, it too is an alpha, but its testing thoroughness seems far better).

As for which is "better", well, it really depends on purpose. It looks like a case of weighing up "Fast, easy development" versus "fast easy ongoing operational support". As a business we are currently leaning towards the operational ease, as products tends to spend most of in production, not development (unless you are the UK government of course).