// the find
event-driven-io/Pongo
Pongo - Mongo but on Postgres and with strong consistency benefits
Pongo is a TypeScript library that accepts MongoDB-style calls, either through its own client or a MongoClient-shaped shim, and translates them into SQL against PostgreSQL. Each collection is a table with a JSONB data column. It is for Node teams that already know Mongo's query syntax and want their data on Postgres for ACID guarantees, licensing reasons, or to share infrastructure with the rest of the stack.
- Each collection is an ordinary Postgres table with _id, a JSONB data column, _version and _archived, so anything else that connects to the same database can query it with plain SQL. There is no separate document store to operate or back up.
- The README shows the generated SQL for $push and $elemMatch, which makes the translation inspectable. You can run EXPLAIN on what Pongo emits instead of trusting an opaque layer.
- It is a library, not a wire-protocol proxy like FerretDB. It works on managed Postgres such as Supabase or Cloud RDS without an extra process, and it can share a pg connection pool with the rest of the app.
- The README says the project is 'far from being 100% compliant with MongoDB' but never lists what is supported. Before migrating, you will have to check each operator you use against the source or your own tests.
- The JSON query path depends on GIN indexes over the data column, yet the DDL in the README creates none and never mentions indexing. Without them, every path filter is a sequential scan, and the docs do not warn about it.
- The 'faster than MongoDB' claim links to an EnterpriseDB whitepaper. EnterpriseDB sells Postgres, so treat that as a reason to benchmark your own workload, not as evidence.
- The shim example does not run as written. It constructs the client from postgresConnectionString, a name that is never defined, while the variable above is connectionString. It is a small error, but it is the first code people copy.