The Great Migration from MongoDB to PostgreSQL

Original Article ↗ Hacker News Discussion ↗

A technical post on migrating from MongoDB to PostgreSQL prompts broader reflection on how the industry moved from the NoSQL/document-database hype back toward relational systems. Commenters argue that most application data is inherently relational and praise PostgreSQL’s maturity, SQL features, JSON support, and ecosystem, while acknowledging areas where document stores or key–value systems (like MongoDB, DynamoDB, or Cassandra) still make sense, especially for horizontal scaling. There is also criticism of MongoDB’s past marketing and licensing changes, and repeated warnings that choosing a database poorly early on can lead to costly rewrites later.

State of MongoDB vs PostgreSQL and Others

  • Many commenters see PostgreSQL as the “default” general-purpose database now, with MongoDB and other NoSQL systems relegated to niches.
  • Some argue MongoDB is “on life support”; others counter with its strong revenue growth and large installed base.
  • MySQL is viewed as still widely used but technically behind Postgres; MariaDB is seen as MySQL’s spiritual continuation.

Document Databases vs Relational Databases

  • Strong view that most application data is inherently relational; using a document DB as the primary store often backfires.
  • Repeated stories of painful migrations from MongoDB/CouchDB/RethinkDB back to Postgres for relational and reporting needs.
  • A minority emphasize that document DBs have valid use cases (e.g., form wizards, replicated logs/queues, read-heavy workloads).

MongoDB: Licensing, Business Metrics, and Maturity

  • License changes are widely seen as damaging to MongoDB’s ecosystem and long‑term goodwill.
  • Debate over how to judge health: revenue growth vs large and persistent losses vs cash flow.
  • Some say MongoDB has matured (transactions, joins, better tooling), but distrust remains from earlier instability and marketing overreach.

Postgres Features and JSON Support

  • Postgres praised for robustness, rich SQL, extensions (e.g., PostGIS, FDWs), JSON/JSONB columns, and plugin ecosystem.
  • Discussion that JSON updates in Postgres rewrite the whole object, can cause race conditions, and are not field-atomic like Mongo’s operators.
  • Others argue large JSON blobs in Postgres are usually a design smell; you should model predictable structure relationally.

Scaling, HA, and Operational Issues

  • MongoDB clustering and replica sets seen as “easy out of the box.”
  • Postgres criticized for lacking native, turnkey HA/sharding; real deployments often rely on third-party tools and custom scripts.
  • Counterpoint: vertical scaling + basic replication covers 99% of real-world needs; specialized distributed SQL/NoSQL only for extreme scale.

Hype Cycles and Tool Choice

  • Many frame the NoSQL era as a hype-driven overreaction, now swinging back to relational DBs with JSON support.
  • Consensus that picking MongoDB for relational workloads, or any DB based on fashion/PR alone, leads to expensive rewrites.
  • Recurrent heuristic: “Use Postgres by default; deviate only with a very clear, scale- or workload-driven reason.”