Mongo but on Postgres and with strong consistency benefits

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.