Mongo also got there "first". I mean, Mongo isn't much compared to Rethink, but they're both in the "not a traditional SQL database" camp and Mongo came before and had all the hype first.
I wouldn't be surprised if people a) didn't use Rethink because they're happy with Mongo and its popularity b) hated Mongo and saw Rethink as too similar/didn't research it enough.
I'm not sure if anyone else ran into this, but I evaluated RethinkDB for three separate projects over the years, and there was always that one missing feature. I don't remember exactly what they were, but I think the first time it was secondary indexes, the second was full text search and the third was geo indexes.
Went with Postgres for all three.
When Windows Phone 7 came out, without background tasks, MS was quick to point out that the iPhone didn't originally have it either. It was a silly argument; Neither Apple nor Google were selling phones without that feature at that time.
I'm not saying Rethink did anything wrong. And by bringing up MS, I don't want anyone to think Rethink had the same sense of entitlement as Microsoft.
Your v1 has to compete against your competitors current version, not their 5-year old v1. RethinkDB had a lot of powerful features, but it also lacked a lot of features that for me, and I have to suspect many others, made it an impossible choice.
(Also, I hated the query syntax. I was willing to fight through it, but I often wondered if that was turning people off)
I'm genuinely surprised at the number of people who vetted RethinkDB and are now really concerned with this news. With the number of solutions out there to accomplish the same or more RethinkDB almost seems like a novelty choice. Surely the decision to make it business critical came with the understanding and acceptance that the company might go bust? I'm not sure what was accomplishable with RethinkDB that wasn't with any number of other alternatives or combinations of alternatives.
RethinkDB really managed to build quite a lot of positive feelings in me on the back of not very much technology. But what technology was there seemed very robust. Just kind of incomplete.
My situation was very similar to latch's above. I vetted it earlier this year, after having developed warm fuzzy feelings for it last year at another company. We wound up going with Postgres + Solr because A) we've used them before, B) they performed a lot better than Rethink, and C) Rethink's compensating features (distribution) weren't worth the tradeoff.
I thought Rethink seemed like Mongo done right. Both have a simple document storage model. Rethink embraced "relations" a lot better, and seemed interested in borrowing some good ideas from relational theory. Having a uniform query language was a good idea; the "builder" style was an odd choice but whatever. Where Mongo ignored and failed to address Aphyr's concerns directly (and antirez seemed to emit a cloud of interminable semantics debates) Rethink actually reached out to Aphyr for testing and rapidly took action based on his recommendations. They accepted the criticism readily and went to some effort to be transparent about what they could and could not do. Failover was not a 1.0 feature, so they didn't hose it totally. The admin interface was beautiful. You really felt like you had a simple, powerful tool that you could understand.
Performance wasn't great. This was the showstopper for me. But to be honest, I probably wasn't going to give them a dollar even if it was a lot better. I'm not paying for Postgres or Solr either. I don't know how you bootstrap a database business. The Mongo/MySQL approach of "make garbage, monetize, hope someday you can refactor it into shape" looks obviously wrong stacked up against Postgres, which always took the academic approach of "first make it right, then make it perform." But performance is a feature and it takes a long time to make a database right, let alone perform. I think they took the right approach. It's just a long process, and it may not be compatible with startup culture.
I don't agree. To take a microscopic view of just one of them, consider TIMESTAMP. It was identical to DATETIME, except that if you touch that row, the _first_ TIMESTAMP column gets automagically updated to the current time. This isn't the kind of thing that happens by accident, someone decided that this was desirable and went out of their way to write code to make it happen. The feature caused a great deal of confusion and probably a significant amount of data loss. It's more than merely non-standard or in some sense "less" than Postgres, it's actually inimical to the model of what's going on, in several senses: column "ordering," a data type with behavior. This kind of "here's a bucket of special-cases" sloppiness is thematic for both MySQL and Mongo.
My sense is that the market for NoSQL databases is large enough that RethinkDB could have focused on a particular customer segment and grown from there. So even if Mongo was the dominant player in NoSQL land, it seems at least possible that Rethink could stick it out and win.
Perhaps this is what RethinkDB's strategy was all along with targeting real-time applications. I wonder if they were just... too early?
Early couch had scaling problems. We built a product around it and had a terrible time keeping it running at scale. Ruined erlang for me, too. Not from the language, but the problems with the build tools.
I think couch never caught on because of it's very different querying paradigm that was enough of a friction to mass adoption.(which has only been fixed by making a mongo like DSL in the 2.0 release).
I wouldn't be surprised if people a) didn't use Rethink because they're happy with Mongo and its popularity b) hated Mongo and saw Rethink as too similar/didn't research it enough.