Just use Postgres

Original Article ↗ Hacker News Discussion ↗

A lively debate over the slogan “just use Postgres” weighs PostgreSQL’s rich feature set, strong tooling, and reliability against the simplicity and suitability of alternatives like SQLite, MySQL/MariaDB, MongoDB, and key–value stores. Many argue Postgres is an excellent default for new server‑side applications, especially when you lean into SQL and database features, while others point out its operational overhead, scaling quirks, and vendor lock‑in risks, and prefer SQLite for single‑node or embedded use or specialized systems for analytics and high‑scale workloads. The broader takeaway is that database choice should follow concrete requirements—concurrency needs, data volume, deployment environment, and team skills—rather than one-size-fits-all rules or hype around NoSQL and AI-era vector databases.

Postgres as the “Default”

  • Many agree Postgres is an excellent default: powerful features (constraints, indexes, JSON/JSONB, full-text search, FDWs, RLS, etc.), strong tooling, and widely deployed.
  • Some argue you should lean into Postgres-specific features instead of fearing lock-in; others prefer sticking to more portable SQL to ease future migrations or hedge against licensing changes.
  • A minority note real gaps (e.g., native temporal tables, built-in multi-master HA) and that some advanced HA/replication is effectively paywalled in commercial distributions.

SQLite vs Postgres

  • Pro-SQLite points: embeddable library, “just a file” backups, trivial snapshots, great for single-box apps, desktop/mobile, and small self‑hosted deployments. Some report years of reliable production use, even in regulated contexts, with periodic-snapshot RPOs.
  • Caveats: defaults are unsafe unless tuned (foreign keys off, non-strict typing unless STRICT tables, WAL opt-in); limited ALTER TABLE operations; single-writer locking and potential app-wide blocking; not well suited to certain PaaS offerings.
  • Pro-Postgres side argues that for server apps, a separate DB process is fine, overhead is small, and backup/maintenance are manageable; critics counter that major upgrades, backup/restore tooling, user management, and socket quirks are non-trivial.

MySQL/MariaDB and Other SQL Databases

  • Several see little reason to choose MySQL now, citing historical footguns, stagnation, and Oracle ownership risk; MariaDB is viewed as better than MySQL but still behind Postgres and full of “nasty surprises.”
  • Others highlight MySQL’s mature HA options (group replication, Galera), though Galera’s correctness is questioned.

MongoDB, DynamoDB, and NoSQL

  • One camp: Mongo/NoSQL are overused by newcomers who want to avoid schemas; teams often “recreate SQL badly” on top. Concerns about consistency, denormalization locking in access patterns, and licensing (SSPL).
  • Defenders say most criticisms are outdated or inaccurate: Mongo has sharding, replication, JSON schema validation, aggregation pipelines, change streams, and can scale to billions of documents and high QPS; Postgres also struggles at very large scales or across multiple machines.
  • Dynamo-/KV-style systems: some emphasize needing well-known access patterns; others say schemas and indexes can evolve and that KV can encourage better service boundaries.

Business Logic, ORMs, and Architecture

  • One side advocates writing SQL directly and pushing heavy business logic into the database (procedures, views, constraints) for performance and consistency; examples of long-lived systems benefitting from this.
  • Others report poor developer experience with large stored-proc codebases (tooling, debugging, version control) and prefer hexagonal architectures where the DB is a replaceable adapter.
  • ORMs are both criticized (abstraction, bad queries) and defended (productivity, consistent modeling, sometimes better query generation).

Scaling, Analytics, and Specialized Use Cases

  • Postgres generally scales “far enough” for most companies; if you outgrow it, you likely can afford specialists.
  • For heavy analytics, columnar/MPP systems (Snowflake, ClickHouse, Vertica) are said to outperform Postgres row storage.
  • Horizontal write scaling for Postgres via Citus/logical replication exists, but HA and multi-master stories are seen as weaker than some alternatives.

AI, Vectors, and New Databases

  • Disagreement over “AI is a bubble”: some dismiss dedicated vector DBs; others stress real needs for multimodal and semantic search.
  • pgvector and SQLite vector extensions are noted as ways to keep using general-purpose SQL DBs while adding vector search.

Education and “Just Use X” Advice

  • Bootcamps often teach MongoDB; some see this as giving students an easy but misleading intro (no migrations, implicit schema), others as a valid way to learn trade-offs.
  • Multiple commenters caution against one-size-fits-all slogans: “just use Postgres” or “just use SQLite” works as a heuristic, but real choices should follow requirements, scale, environment, and team expertise.