Document database recommendations v2.0
People sometimes ask me about document databases. For years, my recommendation was simple: if you’re okay with using Windows server, use RavenDB. Otherwise, use MongoDB. That’s it.
With the recent release of Cloud Functions for Firebase, there is finally a third candidate. Firebase has been close to my heart since it was released; the ease of development is incredible, and the realtime paradigm makes for some incredible products. But let’s go back a bit, to before Cloud Functions for Firebase was a thing.
RavenDB has, for years, been my top recommendation for a document database. I did work for the company, adding features to the database, for a few months, so you might think I’m biased, but it’s the other way around — I came to work for the company because I love the database so much.
What’s so great about RavenDB?
The design philosophy it follows is The Pit of Success. By default, the database protects you from common document database errors; the API is kept as small as possible, with more dangerous operations hidden behind an ‘Advanced’ flag — so if you’re using Intellisense, you’ll only see the things you’re more likely to need.
The database is split into two parts: the database itself, which is fully ACID, and the indexes, which are BASE. That allows for blazing fast writes by default with indexing in the background while keeping transactional consistency. And if you need your query to wait for the last writes to be indexed, you can simply ask for it — but then the query will slow down to more traditional speeds.
Indexes in RavenDB can be done automatically, or written in C# to do more advanced things; which would be done on the server in a background thread. This allows us to do some advanced processing, like pulling in data from other documents.
Unfortunately, RavenDB has only been available for Windows server, which is a pain point for many people. However, they’ve added support for running on Linux in RavenDB 4.0.0, which is in Alpha stage right now. When released, this version will be able to run on Windows, Ubuntu (14.04 or 16.04), or on a Raspberry Pi.
MongoDB was traditionally my other suggestion, but only by default.
Don’t get me wrong; MongoDB is a decent database. It’s fast, relatively easy to use, supports advanced scalability features like sharding and replication as well as most operations you’d want to do with a document database.
However, historically, MongoDB has not been reliable. As opposed to RavenDB, it is unsafe by default; server errors are not transmitted to the client unless the client specifically requests it, data corruption was surprisingly common, etc.
They’ve worked on that, and I do believe it is now reliable — at least everyone on the internet seems to think so — but the design philosophy is still a core issue in my opinion.
All that said, I do still recommend MongoDB if you want to run a document database on a Linux server. I’ve tried many other document databases, and none have been anywhere neer as mature.
Last, but not least: Firebase is now my top recommendation. The obvious con is that it is software as a service, running on Google’s cloud rather than on your own service.
However, the database is fast, reliable, extremely easy to work with, and allows for truly serverless web applications: the database itself, with its advanced authorization rules, controls what users can and cannot do, and cloud functions allow you to add any server-side processing.
When using Firebase, a client connects directly to the database, rather than to an application server that would connect for him. This presents some challenges; if you allow your clients direct write access to the server, a rogue client could easily destroy everything you’ve worked on building. Authorization thus becomes a major issue in any such database; they’ve made a new language just for that, called Bolt.
A second issue with Firebase was also related to the lack of an app server in the middle: there was no way to do complex server-side processing, unless you had a server constantly listening for change. Now, with Cloud Functions for Firebase, this issue is solved; you write your functions in node.js, deploy them to Google Cloud, and they respond to Firebase events.
This removes my last objection to using Firebase on a production system; Cloud Functions is still in beta, but expected to be released on the following months. I have already used it successfully myself to solve a problem I had been postponing dealing with.
If you’re happy with SaaS, Firebase is a very good options — but it does use a different development paradigm, where the application is serverless, and clients connect directly to the database.
If you’re happy with Windows (or a hosted solution via RavenHQ), use RavenDB. It really is the best traditional document database out there.
If you must use Linux servers, and can’t wait for RavenDB 4.0, use MongoDB. Beware its pitfalls, and make sure you understand how and when errors are thrown.