Mongo but on Postgres and with strong consistency benefits

Original Article ↗ Hacker News Discussion ↗

A new Node.js library, Pongo, aims to let developers use a familiar MongoDB-style API while actually storing data in PostgreSQL JSONB tables, promising stronger consistency guarantees and easier operations than running Mongo itself. Commenters compare it to projects like FerretDB and AWS DocumentDB, debate whether emulating Mongo’s query language is desirable, and share mixed experiences with MongoDB’s performance, consistency, and operational complexity. Much of the conversation centers on when JSONB-in-Postgres is a good fit, the pitfalls of schemaless documents (validation, migrations, query planning), and the appeal of hybrid models that combine relational columns with flexible JSONB fields.

What Pongo Is

  • Library that exposes a MongoDB-like Node.js API while storing data in PostgreSQL using a simple table: _id UUID PRIMARY KEY, data JSONB.
  • Translates Mongo-style queries into native PostgreSQL JSONB operations; not aiming for full Mongo compatibility, but for the “80% that matters.”
  • Intended benefits:
    • Keep MongoDB “muscle memory” and query shapes.
    • Allow easier migration from Mongo to Postgres without fully rewriting data access.
    • Leverage Postgres features (constraints, foreign keys, generated columns, JSONB indexing, hosting options).
  • IDs are just UUIDs; UUID7 or other formats can be used for better insert patterns.

JSONB vs. Document Stores

  • Many commenters already use a hybrid schema: core fields as regular columns plus a JSONB column for flexible or integration-specific data.
  • Some report large performance wins moving from Mongo to Postgres+JSONB, even with simple wrappers.
  • Others report disappointing JSONB performance (slow aggregates, complex syntax, tricky array indexing) and planner issues due to lack of statistics on JSONB.
  • Suggested mitigations:
    • Generated columns to surface frequently queried JSON fields as normal columns.
    • Expression indexes on JSON paths.
    • JSON-schema validation in the DB or app layer to avoid “schema chaos.”

Consistency, Reliability, and Trust

  • The “strong consistency benefits” tagline is interpreted by many as “you get Postgres’ ACID semantics, constraints, and defaults.”
  • Debate over MongoDB’s consistency:
    • Some note Mongo supports serializable-like isolation and MVCC via WiredTiger.
    • Others cite Jepsen analyses of past Mongo versions (and Postgres too) showing real-world anomalies.
    • A recurring theme: Mongo’s history of weak defaults, marketing vs. reality, and bugs has eroded trust, even if current versions are better.

Distributed / HA Comparisons

  • Some argue Mongo’s defining feature is built-in sharding/replication; others counter that many Mongo and Postgres deployments are effectively single-node or simple replicas.
  • Several consider Postgres HA/clustering tooling fragmented and “Rube Goldberg,” while Mongo’s replication is seen as one of its strongest points.
  • Others prefer distributed SQL systems (CockroachDB, YugabyteDB) and note Pongo could work with any Postgres-compatible JSONB implementation.

Skepticism and Adoption Questions

  • Some dislike Mongo’s query language and question why anyone would emulate it on Postgres.
  • Counterpoint: easing migrations and preserving existing code/tests is valuable; Pongo is seen as a bridge rather than an endorsement of Mongo’s design.