Moving Fulcrum

RethinkDB Failure: Product, not Marketing

Published October 7th 2016

Both RehinkDB and MongoDB started in the same year, and raised similar amount of seed funding. However, RethinkDB is dead. Many attribute this to better marketing on Mongo's part. Looking deeper though, it seems its the core RethinkDB product to blame for its failure.

1. No official Java driver till Dec, 2015

RethinkDB didn't have an official Java driver till Dec, 2015 (and even that only supports Java 8). A 7 year old database, that doesn't have a Java driver till its 7th year! While Java may not be considered 'cool' in the Bay Area, in the rest of the entire world of enterprises, Java is the number 1 language.

By not having an official Java driver for the majority of its life (and only ever releasing one for latest Java version), RethinkDB made clear that it was a database for startups only. Period.

Heck, it never got around to having a C# driver...

2. No Java POJO conversion library

With Mongo, we use the Spring Data MongoDB library. It takes care of converting plain Java objects to/from the json format that Mongo drivers need. It results in typesafe, high level code and we never have to interact with the low level Mongo driver.

With RethinkDB, we found no such thing. The only way to interact with it was through its Java driver, which forced us to manually convert our objects to/from Maps. This essentially wiped out all the ease of using a document database in the first place. It meant everything that takes a single line with Spring and Mongo would take many, many lines with RethinkDB.

3. No Automatic Failover till Aug 2015

How many production Mongo clusters you know that run with only 1 node? None. Since the beginning, MongoDB claimed High Availability by allowing you to run with a replica set of 3 nodes, and if one failed, the other took over automatically.

Implementation issues of Mongo aside, by not having this feature till its very last year, RethinkDB was 'automatically' not the choice for anyone comparing it to Mongo.

4. No equivalent to Mongo Cloud Manager

This is described in detail in the DripStat blog post. Basically Mongo's cloud service takes care of installation, upgrade, backup and restore of Mongo clusters, on your private servers. Thereby managing to automate the entire administration of Mongo.

RethinkDB did do a partnership with Compose which it (wrongly) thought resulted in solving the above problems. However, Compose cannot be used in real production apps. It deploys the database outside your virtual network which results in high latency, unreliable network and data transfer costs. Its recent 'Enterprise' plan is order of magnitude more expensive than Mongo Cloud and doesn't work everywhere.

Not having a managed administrative service resulted in significantly increased administrative cost for users, again pushing people towards Mongo.

5. Trying to be Firebase

RethinkDB sacrificed all of the above for 'changefeeds', its 'realtime' push based feature.

It is indeed cool to show in a demo that changing data on one end, automatically 'pushes' the change to another client. However, the majority of the world doesn't care about that. They just want to save their signup data, and user setting data and all kinds of other data that doesnt need to be 'pushed' over websocket for that 'its sooo cool' effect.

Firebase was a tiny company that sold for an insignificant amount to Google. It is used by either startups or by large corps for a very small subset of data. The majority of data in the world is accessed over REST APIs and stored in 'non-realtime' databases. The success of every other database in the world, that is not Firebase, should have proven to RethinkDB, that their efforts were being put in the wrong direction.

Even here though, RethinkDB was far more complicated to setup and use than Firebase. It literally tried to clone Firebase by offering Horizon, but that too had a long way to go.