> Don't let your bad experiences with overhyped database
<rant>
I've picked up RethinkDB once. That was early 2016, it had existed for a while (about 6 years at that time), was deemed a stable production-ready database, had passed Jepsen tests without any serious issues, etc etc. Was it overhyped? Could be but I don't think so - it wasn't shoved down anyone's throat, there weren't any "web scale" memes about it, just a post here on HN, every couple months or so, whenever they made some improvements or posted great technical articles. Looked totally good to me.
It was great for development. Yet, it ended up as a small disaster when the production systems gained some traction. Awful disk usage (I've had to read the source to investigate the serialization formats and be aware about undocumented efficiency considerations), led to servers grinding to a halt due to heavy I/O. And when nodes had sustained the load, they had slowly leaked memory (that was not the caches, unless cache size limiters were broken), so eventually kernel had to invoke OOM killer and that caused a node restart. This resulted in a daily/bi-daily 1-minute downtime blips on the health monitoring. Essentially, it was a huge waste of resources for a couple of nice-to-have features. And in the meanwhile, the company who made the database had shut down - after 7 years of existence.
I've gradually replaced almost all of it with CockroachDB which took a fraction of disk space and CPU time. I went for a distributed DB because I had three nodes anyway; and I was feeling adventurous enough to try CockroachDB only because of the idea that I can trivially switch to tried & trusted PostgreSQL at any moment. Fortunately, it seems to work well for my current load and dataset, although that could be just me being lucky.
</rant>
Now, I believe, unless something is a toy project or one accepts the risk to rewrite things to use a different storage, a database (and other core technologies) should be chosen in a conservative fashion. Unless there is a plan B.
I have a plan for a small new toy project which could possibly benefit from a graph+document database. I've looked at ArrangoDB recently and it could be a good fit. Yet, if ArrangoDB would start to disappoint for me, say, after a few months in production, there will be no plan B - unless I spend more resources designing this escape hatch than I'd save by using a fancy graph database. So I'm picking PostgreSQL - something that may require a bit of extra work but that I'm 100% sure about.
Just an opinion: long-term safety beats development convenience.