- lack of mass adoption - they didnt solve a problem everyone had
- lack of nitch adoption - they didnt solve a problem a few people had badly
I can tell you 4 features that I view more important than change subscription
- can run in any ecosystem - pouchdb/couchdb and waterline are examples of single apis in different environments. Even being able to use the database 100% in memory as a redis alternative would be nice.
- supports transactions across shards natively - this is a difficult but important feature that mongodb is missing
- supports document id transaction and table transaction - if Im only updating two documents, I have no interest in making many financial transactions wait for a table to be finished being used when I only care about 2 documents in that table.
- "sync" feature on a table - pouchdb supports this for syncing a client with a server
Rethinksb failed because, despite its sweet name, it wasnt solving that important of problems.
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.
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.
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.
Unfortunately, popularity doesn't imply merit and merit doesn't imply popularity.
* 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.source: https://rethinkdb.com/docs/consistency/
However, certain operations on a single key, like incrementing a counter, are atomic.
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.
Very, very painful problems are very, very valuable.
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.
https://www.rethinkdb.com/faq/#are-rethinkdb-transactions-at...
Make a private (non-OSS) version optimized for Business (B2B), do external consultant jobs and pretty much ask for donations from the big players/users. This is a common problem from almost every OSS project and so far the only one that is doing this is OpenSSL.
1) An Stable "enterprise grade" version which receives fixes and minor performance updates for at least 5 years, maybe even charge extra for another 2-5 years round (just like Microsoft does).
2) Reports: Business love reports, if they add a way to generate reports straight from the DB (like Oracle and SQL Server) is a killer feature most of the time.
3) Customer Support.
This shutdown therefore goes a long way to say how talented and ethically correct the team was, something extremely evident in how they put correctness and reliability in front of performance.
In short, RethinkDB is a very solid piece of software that does well where (many) other NoSQLs fall short, that is:
Now, what could have they done differently to stay afloat? What avenues do we have to fund fund such great projects, whose point is being OSS? (I mean, one of the selling points of RethinkDB is that one can trust it in this land of NoSQLs that promise but don't deliver, and this is in part thanks to their open development processes)