Would much rather have "Mongo" for SQL like this:

https://github.com/microsoft/documentdb

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.

    create table document (
      id uuid primary key default gen_random_uuid(),
      doc jsonb
    );

It's somewhat of a secret, but AWS's JDBC driver for DocumentDB supports Mongo as well

Let's you interact with Mongo as if it were a regular SQL JDBC database

https://github.com/aws/amazon-documentdb-jdbc-driver

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?

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.