Postgres is eating the database world

Original Article ↗ Hacker News Discussion ↗

PostgreSQL is increasingly seen as the default general-purpose database, praised for its robustness, rich feature set, extensions, and strong ecosystem that let it absorb many use cases once served by specialized systems like search engines, analytics databases, or NoSQL stores. Commenters highlight real pain points—non-deterministic query planning, single-node and process-per-connection limitations, write amplification, and weaker full-text search compared to tools like Elasticsearch—yet argue these are often manageable with tuning, extensions, or architectural choices. The overall view is that while Postgres cannot and should not replace every niche database (e.g., ultra-high-throughput transaction engines or HA-first distributed stores), its steady evolution and flexibility make it a compelling default for most applications.

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.