RethinkDB 2.0 - why I'm excited

by Paweł Świątkowski
15 Apr 2015

Just yesterday RethinkDB 2.0 has been released and announced production-ready. While many of us may be unaware of that, this might made quite a change to web development panorama. I’m going to try to briefly explain why I think so and why I’m excited.

It was a really hot summer of 2013 when our PM announced that now we have to think about creating a statistics/tracking system for our big corporate client we were building other product for. This was not what we were experts at. We had no experience in such fields but accepted a new challenge. After brief analysis we concluded that we cannot use PostgreSQL on that (and we were using PostgreSQL for everything so far)1. I was the one to search for other viable solutions in a wild world of NoSQL.

I spent two weeks examining nearly 40 NoSQL databases - from Hadoop/Hive and Cassandra, through Riak to MongoDB. I was focused on finding the one with efficient set operations and decent fidelity. Long story short, there was no database better in set operations than Redis2. It had but one huge drawback – being in-memory-only. I maneged, however, to find one little-known gem (not as in ruby gem) called RethinkDB. It had set operations, joins (!), secondary indices, easy-as-pie sharding, nice syntax and ruby support out of the box.

We were not using most of those features but it was a clear that something big is happening. I was following news about RethinkDB development and never ceased to be amazed. Now here we are, at dawn of the era of production-ready RethinkDB, so I’m goin to list feature I’m most exited about.

  • Geospatial. I used PostGIS. It’s great for everything geo-related. RethinkDB also has a great support for geospatial queries.

  • Pub/Sub. There is always a project out there that needs it. You can do it with RethinkDB pretty well too.

  • Last but definitely not least, changefeeds! With changefeeds you can bind to whatever part of your data in database and receive instant notifications about what is change. It comes as a JSON formed like { :old_val => nil, :new_val => { :id => 1, :name => 'Slava', :age => 31 } (this means a new object was created). You can use it with filters, joins, text matching… basically everything RethinkDB provides. It’s really powerful feature when combined with websockets, but can be also used to decouple some common tasks from your main application: for example you may watch changes on some objects and sens notification emails when they happen. Read more about changefeeds here.

If you are ruby developer like me, you will also like the fact that there is a really good ORM3 for RethinkDB called NoBrainer. It feels a bit too much ActiveRecord-y sometimes but is really nice to use with your Rails application. Some mainstream gems have support for NoBrainer too, most notable being Devise and Kaminari. I myself wrote adapter for Carrierwave.

There is one more important thing to mention. In our tests ruby driver proved to be a bit slow for massive query amount (over 95% of time was spand on waiting for mutex to release). This is hopefully no longer an issue, as with 2.0 version a new driver with EventMachine support is released, which would probably solve that.

I’m really looking forward to writing something serious supported by RethinkDB in near future. Hopefully, I’ll have this pleasure soon.

  1. Eventually, requirements have changed a bit, PostgreSQL become better at being NoSQL database than most NoSQL databases and we ended up using it, but thats not the point of the story… 

  2. I think this is still totally true. 

  3. Well, not really ORM, as RethinkDB is document database, but author calls it so. 

end of the article

Tags: rethinkdb

This article was written by me – Paweł Świątkowski – on 15 Apr 2015. I'm on Fediverse (Ruby-flavoured account, Elixir-flavoured account) and also kinda on Twitter. Let's talk.

Related posts: