MongoDB vs RethinkDB: Comparing Oranges with Oranges

For years, MongoDB's being the darling for NoSQL users. And with good reason - Out of all the NoSQL database platforms out there, Mongo happens to be the one with the biggest ecosystem built up around it - user groups, third-party clients and ODMs and tools, plus so much more.

But Mongo's had limitations. A rather convoluted query language, the complexity behind sharding one's datastore, and more. And that's where I'd say RethinkDB could move in!

This post aims at a very broad overview of the key differences between Mongo and Rethink. I'd love to write more detailed posts soon, with actual performance benchmarks.

RethinkDB?

RethinkDB's an open-source NoSQL database, that can store JSON documents with dynamic schemas. In that sense, it's very different from Mongo, which stores BSON documents. BSON's essentially an extension to JSON, to support more types like timestamps, lat-long coordinates, apart from regular JSON's types - numbers, strings, booleans, arrays, nested objects and null types.

I feel one of RethinkDB's biggest advantages stems from ReQL, its query language. It's a unified and chainable language, that can be used from languages like Python, Ruby and Javascript without the need for embedding it as a string in code, the way one would use raw SQL. Apart from that, the succinctness is very appealing. Consider the following JSON document, that resides in a collection called users:

{
"active": true ,
"email": "jane@doe.com", 
"id":  "3ded6bc6-34d9-439a-8565-fa9e87dedec2" ,
"login":  "23-May-2016"
}

If this was a Mongo collection, a query to fetch user IDs and emails with logins for 23rd May would look like:

db.users.find({
  "login": "23-May-2016"
}, {
  "id": 1,
  "email": 1
});

That's a little...verbose? Check out the same query in ReQL:

r.table('users').filter({'login': '23-May-2016'}).pluck('id', 'email').run()

That's definitely shorter. Less syntactical sugar, which is a great thing. But what's interesting, is how comprehendible the query is - at first glance, it's not very apparent what the Mongo query means, with "id": 1 - but ReQL's pluck seems to make more sense.

By the way, ReQL allows you to add Javascript expressions within the query, for all sorts of things - pattern matching, accessing an HTTP API, map/reduce and more. These expressions run on a V8 engine - so, great performance.

Now, what might the same query look like in Python?

import rethinkdb as r

# Database connection glue, not adding it here.

users = r.table('users').filter(r.row['login'] == '23-May-2016').pluck('id', 'email').run(conn)

Not much has changed - the query's the same except for the filter clause.

Changes

RethinkDB's second biggest advantage - streaming changes, or changefeeds. They allow clients to receive changes on a table, a document or even the results of a query - so effectively, any ReQL query can be turned into a realtime feed.

Let's take up the users collection again. What if we want to monitor changes on the table's documents?

r.table('users').changes.run(conn).each{|change| p(change)}

Running this query would give you a realtime stream of JSON documents. Now let's say a document with id: 1 is updated. The changes would be pushed to the client running the query above, and it would look like:

{
  :old_val => { :id => 1, :name => 'Jane', :age => 22 },
  :new_val => { :id => 1, :name => 'Mike', :age => 30 }
}

This makes RethinkDB a great choice for anything that requires monitoring data in realtime - chat/bot platforms, realtime analytics. Take your pick!

Administration

I never found a great admin interface for Mongo. Sure, generating CRUD admins wasn't so complicated - but finding a great UI for managing a Mongo cluster was pretty painful. That's something RethinkDB addresses - the admin interface is a gem. Not literally - it's not exactly a Ruby app!

The RethinkDB admin console gives you a pretty decent status check on your cluster - and shards, if any. It lets you literally shard tables with 1 click. And it's got a great data explorer, for writing queries and running them. A nice little data browser might be nice, but they're looking at building it, so it'd be pretty epic when that's rolled out.

...but nothing's perfect.

Sadly, RethinkDB has its limitations too.

For one, it's not ACID-compliant. If you want to enforce a strong schema, you might as well use a relational database. Second, RethinkDB prefers to go for data consistency, as opposed to write availability. That can be an issue if you do intensive writes regularly, and at frequent intervals. Also, it's important to understand how the RethinkDB architecture works under the hood, if you want to write high-performant queries.

I think I'd end this with a tweet that sums up RethinkDB.

"RethinkDB looks like a MongoDB done right: MVCC, non blocking writes, durability by default, v8, incremental vacuum, easy sharding, …" --- @herodiade

Give it a shot. Spin up a RethinkDB instance for your next app, and check it out for yourself