QueryLeaf: SQL for Mongo
13 comments
·May 8, 2025ttfkam
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.
aleksi
FerretDB v2 is built on top of this extension. See https://github.com/FerretDB/FerretDB
VWWHFSfQ
We're seeing a convergence of document DBs adding relational features, and relational DBs adding document features. At this point I find the best of both worlds to simply be PG with JSONB.
create table document (
id uuid primary key default gen_random_uuid(),
doc jsonb
);
This alone will give you a huge number of the features that Mongo provides, but also the full power of Postgres for everything else.victor106
this makes so much sense.
I also wonder if there are some specific capabilities of MongoDB that this pattern does not support?
etse
Maybe not capabilities, but I'm wondering if Postgres has gotten any easier to scale horizontally. The administrative overhead of scaling and maintenance with MongoDB seemed lower to Postgres to me.
Would love to hear from others with more Postgres than I.
zareith
Curious if there is something similar that works with sqlite.
aleksi
There is FerretDB v1, which provides MongoDB protocol for SQLite. See https://github.com/FerretDB/FerretDB/tree/main-v1
maxbond
As of 3.38 (or 3.45 if you meant a binary JSON structure specifically) https://sqlite.org/json1.html
gavinray
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
gitroom
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?
halalfatal
[dead]
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.