Would much rather have "Mongo" for SQL like this:<p><a href="https://github.com/microsoft/documentdb">https://github.com/microsoft/documentdb</a><p>I am skeptical that SQL with Mongo backing it would be at all performant except in the most trivial cases. On the flip side, Postgres's jsonb indexing makes the inverse very doable.
I can appreciate the technical aspect of a translation layer, but I struggle to understand the use case for a tool like this. If your data is inherently relational, then you should be using a relational store anyway. And if it isn't, trying to hammer it on-demand into something that looks relational is going to eat you with performance implications. Unless I'm missing something.
It's somewhat of a secret, but AWS's JDBC driver for DocumentDB supports Mongo as well<p>Let's you interact with Mongo as if it were a regular SQL JDBC database<p><a href="https://github.com/aws/amazon-documentdb-jdbc-driver">https://github.com/aws/amazon-documentdb-jdbc-driver</a>
Honestly, putting Mongo and SQL together always confuses me a bit. I'm way more comfy with Postgres and jsonb. Anyone else feel like scaling Postgres is still kinda a pain?