That sounds pretty fair. I think the RQL Builder issue is a bit bigger than that since it would make writing your own DSLs a bit more awkward, with more overhead. I think a simple published protocol would be the better alternative. But even so, it&#x27;s not insurmountable and there are databases with much much more awkward APIs. RethinkDB&#x27;s isn&#x27;t all that compelling IMO, but at least it&#x27;s not actively hostile.<p>Cloudant gets most of the rest correct. Their (dedicated) clustering has been largely flawless IME. Their availability probably the best of any system I&#x27;ve used (database or otherwise). Very very impressive. And their integrated Lucene takes a whole category of issues out of the equation.<p>They don&#x27;t have transactions either though. Which is a bigger issue than in RethinkDB since they also don&#x27;t have joins. If you need to dematerialize a navigable tree into your documents that&#x27;s easy enough. But what happens when the source-of-truth for your tree (another document in my case) changes? You have to reprocess the entire live database. The fact that you can&#x27;t do that atomically mean you either: A: Hope for the best. Or B: Do a lot of extra work implementing processing that will (hopefully) converge on eventual consistency.<p>I feel like RethinkDB is moving up my list during this thread though. So there&#x27;s that. :)<p>The lack of integrated full-text-search that provides decent guarantees is a real sticking point, but outside of Cloudant I can&#x27;t think of another NoSQL solution that attempts it.<p>I&#x27;ll say this though: If RethinkDB resolved the search issue, it would probably be <i>THE</i> DB to use IMO. RQL (despite the space I&#x27;ve given it) is pretty petty in comparison. And lack of multi-document atomic transactions are much less of an issue with the schema flexibility afforded by JOIN support.<p>Even without resolving it I think I&#x27;m convinced enough to give it a closer look.