Former rethinkdb developer here. Sharding and replication just work out of the box. Connect the servers to each other with "rethinkdb --join otherserver", then use the web dashboard or the client APIs to specify how many shards and replicas for each table. Send queries to any server in the cluster and they get routed automatically.
The problem with a feature comparison between Mongo and another database is that feature comparisons rarely include the features that Mongo lacks. Mongo looks good if you ask about sharding or replicating, but Mongo looks terrible if you ask about losing data or leaking memory. But nobody asks about losing data or leaking memory because they reasonably assume that a popular data store wouldn't do those things. That assumption, while reasonable, would be wrong.
Think of this like Maslowe's hierarchy of needs. Sharding and replication are up at the top with self-actualization stuff like job satisfaction and feeling love toward animals. Meanwhile Mongo is missing the real basic stuff, like actually keeping your data, which is down with food, water, and shelter. You might think you care about replication, but you don't care about replication when both your database servers run out of memory at the same time.
> but Mongo looks terrible if you ask about losing data or leaking memory
Sorry, but this is just not true for many years now. Mongo has its warts but reading old stuff again and again feels strange and like pure hate. If your claims have some recent sources I am happy to hear them.
The list of problems goes on, but if you want really current at a local presentation a few weeks ago a user who's actually pretty positive about MongoDB reported data loss without hardware failure with what is supposedly a safe configuration. If even experienced people who like Mongo are still losing data eight years after publich release there's a problem. The claim that it's "not true for many years now" is the result of buying into PR and fanboyism.
I would expect these bugs to keep occurring, because they're still approaching the development of the consensus algorithm incorrectly. Instead of formally proving correctness, they're doing something that seems right and then patching bugs when they are discovered.
Nope. However, "time to hello world", while certainly a large factor in the success of development tools, is not always the most relevant criteria from an engineering perspective. Cf. PHP.
Anyone got an insight into how well this is going? Compared to when the company was active, how fast is progress? Would you bet on Rethink in this day and age?
I did bet on it and so far I'm happy as long as it continues to work. Sure, I would like it to be developed further, but what I have now is great and works well.
As for progress, it slowed down to non-existent during the handover period, and now seems to be picking up.
Great to hear that! Is there any issues close to being show-stoppers or any "it would have been immensely helpful to have this but I can work around it" features? Also, what would be the thing that RethinkDB is really good at that makes you keep using it?
1. It's distributed. I can elastically add/remove nodes. I need this not so much for scalability, as for reliability, and I want to be future-proof.
2. Changefeeds. Nothing else even comes close, and my entire application is built around them.
I have no show-stoppers. The thing works. Sure, I'd love to see some things done differently (ReQL looks nice at a first glance, but has many limitations in practice, causing code that ends up being quite complex), but overall even if it were to stay exactly the way it is now, I'd continue using it.
Looking at the graphs on github you could say development has slowed down, but i'd like to argue that since there is no commercial incentive anymore the project seems to be much more focussed on stability. And when bugfixing you write less lines while spending the same amount of time.
To me focus on stability is the most important thing in a database so this makes me happy as an ops person, get it stable first and then if needed add more features. though i think rethinkdb is already quite feature complete.
In my personal opinion (based on heavily using RethinkDB for two years), many of the core issues of RethinkDB are related to performance, not bugs. I had bet on where RethinkDB would end up performance wise, had development continued with people who really understand how it works doing fulltime development.
I'm really happy to see progress again. Hopefully we'll see more... I appreciate everyone that worked to make this possible.
side note: the node driver in npm still hasn't been re-published with the license type in the package.json, so doesn't show the license. Only noting as this can cause issues in some organizations.
- Setup of a replica set: is it easier/faster than with Mongo (which I find complicated)?
- Sharding: Easier than with Mongo?
- Rethink's query language: Is it really better than Mongo's after you used it for some time?
Happy to hear more insights if you know more noteworthy stuff and please no bashing of any of them. Just try to make an educated decision.