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 overhea

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's not insurmountable and there are databases with much much more awkward APIs. RethinkDB's isn't all that compelling IMO, but at least it's not actively hostile. Cloudant gets most of the rest correct. Their (dedicated) clustering has been largely flawless IME. Their availability probably the best of any system I've used (database or otherwise). Very very impressive. And their integrated Lucene takes a whole category of issues out of the equation. They don't have transactions either though. Which is a bigger issue than in RethinkDB since they also don't have joins. If you need to dematerialize a navigable tree into your documents that'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'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. I feel like RethinkDB is moving up my list during this thread though. So there's that. :) The lack of integrated full-text-search that provides decent guarantees is a real sticking point, but outside of Cloudant I can't think of another NoSQL solution that attempts it. I'll say this though: If RethinkDB resolved the search issue, it would probably be THE DB to use IMO. RQL (despite the space I'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. Even without resolving it I think I'm convinced enough to give it a closer look.