RethinkDB didn't fail because any of those things. As far as we can tell without an actual post mortem, it failed because RethinkDB -- the company -- didn't make enough money.

Going by the public information on their website, the only way the company was making money from its product was via support and training.

The problem with making money only with training and support is that it falls flat when the product and documentation are so well done barely anyone considers these things important enough to spend money on them.

Additionally the website doesn't really provide much information on these services other than a contact form. If you're not already in touch with RethinkDB devs, you're probably more likely to ask a local contractor or specialised training company for help instead of reaching out to RethinkDB.

By all appearances, RethinkDB has been pretty successful as an open source project. It has a strong and active community, it is well represented at meetups, conferences and podcasts, it has 16k stars on GitHub (MongoDB has only 10k, MariaDB and MySQL have only 1k each).

But the company was not able to turn any of those numbers into revenue. Downloads, GitHub stars and Twitter mentions don't pay to keep the lights on. A successful open source project does not equal a successful commercial enterprise.

Oh no, more starts on Github than MariaDB? Must be popular then! /s

In all seriousness the OP nailed the issue. The company is not successful because of the "issues" with the product. There is a very direct correlation there, stop trying to make it look like the failure of the company did not have anything to do with the product and that the product is perfect/popular/whatever.

I knew someone would make fun of GitHub stars eventually, which is why I was hesitant to mention them.

Yes, RethinkDB wasn't more popular than MongoDB or MariaDB. Of course not. But if you followed the JS ecosystem or Hacker News or podcasts or any of the usual suspects it would have seemed that RethinkDB was quite successful for its size.

People talked about RethinkDB. Whenever someone talked about realtime or streaming data, RethinkDB would come up. That RethinkDB felt so ubiquitous despite its low rank in Google trends or even on StackOverflow speaks to how well the team knew how to make themselves heard.

I'm not saying RethinkDB itself is without fail. The most overhyped feature is realtime change feeds and those don't even work for all types of queries (especially aggregates and joins just aren't supported for that). Based on the documentation it also doesn't really sound like change feeds can work at scale.

But RethinkDB certainly managed to catch people's attention. They just couldn't turn that attention into revenue. And considering you actually have to go out of your way to find out how to give them money when looking at their website, that's not surprising.

Even if RethinkDB had been the best thing since sliced bread, it seems like they would have still failed as a company because of this. To put it into online marketing terms: they certainly had the traffic, but they couldn't get any conversions.

I strongly disagree. I think it failed because it failed to gain popularity for social reasons. It solved a lot of very important correctness problems. On the other hand MongoDB is successful despite having many serious problems. The initial versions were so bad that it had no right ever becoming popular.

Unfortunately, popularity doesn't imply merit and merit doesn't imply popularity.

Im not saying it needed any of these features but I view these features more important than what rethink had to offer. What rethink did offer was redis + new query lang + persistance. I dont think popularity was the issue

I think a very important "selling" point that is not emphatized enough is how it addresses upfront with intellectual honesty in the "architecture" section of the docs[0] many important questions that other databases sometimes hide away to sweeten the deal, that is:

  * How does it position itself against the CAP theorem?
  * Will it ever lose my data during normal operation? (i.e. what are the consistency guarantees)
  * What happens when 1...N nodes go down?
  * What are the requirements for a well performing cluster?
  * What are the limitations in terms of document size, number of documents, ecc?

The point I'm trying to make is that after reading that document, one can quickly and completely understand if RethinkDB suits one needs or not, without "surprises" down the road.

0: https://rethinkdb.com/docs/architecture/

I agree with the comment about distributed transactions - basically, Mongo had the first mover advantage and Rethink (albeit a great platform and easy to setup / administer) needed a big differentiator. That's actually why I'm using cockroach right now, they picked a great problem to solve (cross dc / cross continent transactions) that enables a ton of developer use cases.

Do you mean 'niche' rather than 'nitch'?

Thank you. My heart nearly stopped there.

Does RethinkDB not support transactions? I thought it did.

"RethinkDB operations are never atomic across multiple keys. For this reason, RethinkDB cannot be considered an ACID database."

source: https://rethinkdb.com/docs/consistency/

However, certain operations on a single key, like incrementing a counter, are atomic.

I wish they had added transactions. It seems like such an important feature.

ACID correct distributed transactions create very, very painful performance problem because you have to lock across multiple physical machines separated by network connection(s).

Or y'know, you just don't do them correctly and accept a substantial rate of quietly corrupted data.

There isn't really a good option unless you have absurd amounts of money compared to your transaction volume.

ACID correct distributed transactions are possible. Google's F1 paper shows how: https://static.googleusercontent.com/media/research.google.c...

Very, very painful problems are very, very valuable.

They are possible but they are not possible to make per formant compared to the alternative.

Google falls under the "absurd amount of money" camp.

> Protocol Buffers have performance implications for query processing. First, we always have to fetch entire Protocol Buffer columns from Spanner, even when we are only interested in a small subset of fields.

There are a number of performance costs documented in the paper. Simply because you can solve it via money doesn't mean it works for all situations.

Maybe I'm reading this[1] wrong, but it doesn't sound like it does.

https://www.rethinkdb.com/faq/#are-rethinkdb-transactions-at...