Postgres is eating the database world

Original Article ↗ Hacker News Discussion ↗

Query planner behavior and control

  • Several commenters praise Postgres but complain about its non-deterministic query planner.
  • Pain points: planner choosing sequential scans or “wrong” indexes, dramatic performance swings from small predicate changes, join order issues, and collapse limits on join reordering.
  • Workarounds mentioned: EXPLAIN ANALYZE, disabling specific plan types (enable_seqscan = off, etc.), tuning random_page_cost, CLUSTER to improve index/table correlation, and rewriting joins.
  • Some want explicit plan hints; others argue the planner is usually right and problems often stem from stats, vacuuming, or schema/query design.
  • Third‑party extensions like pg_hint_plan offer manual plan influence.

Materialized / incremental views

  • Strong interest in incremental view maintenance to keep complex analytics “fresh” in real time.
  • Current common workaround: materialized views plus scheduled refresh (e.g., pg_cron).
  • Extensions like pg_ivm exist but have many restrictions; this may explain why it’s not core.
  • Debate on feasibility: some see it as “just an index over a query,” others point to differential dataflow systems (Materialize, Noria, streaming frameworks) as evidence it’s possible but complex.

Admin, upgrades, and operational experience

  • Many report Postgres is now easy to administer; autovacuum is considered effective.
  • In-place upgrades are said to work well, but some still experience painful dump/restore workflows, especially with extensions like PostGIS.
  • Tools mentioned include pgAdmin, dBeaver, web clients; experiences with pgAdmin are mixed.

Use with .NET / EF Core

  • Multiple reports of smooth production use with EF Core and the Npgsql provider.
  • Generally described as stable, performant, and promptly updated.

Comparisons, limits, and alternatives

  • Postgres widely praised as a versatile default; some companies standardize on it over Oracle/MySQL.
  • Skeptics note technical debt, process-per-connection model, write amplification, and poor fit for ultra-high-throughput transactional systems or HA‑first distributed use cases.
  • Specialized systems (TigerBeetle, Cassandra/Dynamo, Kafka, Elastic, ClickHouse, DuckDB, SQLite) are seen as still necessary in certain niches.
  • Debate over Postgres full-text: built-in FTS considered weaker than Elasticsearch, but extensions (ParadeDB, PGroonga, pg_trgm, pgvector, hybrid search) significantly improve capabilities.

Ecosystem, compatibility, and hype

  • Extensions and protocol compatibility are viewed as major strengths; many “new databases” are perceived as Postgres-backed or Postgres-adjacent.
  • Some see Postgres enthusiasm as fad-like; others point to its decades-long history and repeated “hype cycles” where people return after trying trendy systems.
  • New projects aim for Postgres compatibility without reusing its codebase, to tap into existing tools and developer preferences.