PostgreSQL is the Database Management System of the Year 2024

Original Article ↗ Hacker News Discussion ↗

High availability, replication, and upgrades in PostgreSQL

  • Many commenters praise Postgres but see replication/HA as its weakest “out of the box” area.
  • Tools mentioned: Patroni, pg_auto_failover, repmgr, Bucardo, Pgpool-II, MySQL-style Galera-like solutions, and hosted options (e.g., neon.tech) that make replication a toggle.
  • Some want a native, simple, cluster-aware Postgres with built‑in seamless failover and upgrades, similar to MySQL InnoDB Cluster.
  • Approaches to upgrading: dump/restore, pg_upgrade --link, and logical replication; the latter is powerful but still caveat‑heavy.
  • There is a desire for a de‑facto open‑source tool that manages logical replication and failover observability cleanly.

Ecosystem, extensions, and “Postgres is enough” debate

  • Postgres extensibility is heavily praised: Citus for sharding/columnstore, PostGIS, Timescale, AGE, OrioleDB, HTTP-from-SQL extensions, etc.
  • One view: for ~90–95% of use cases, Postgres plus extensions is sufficient, and starting with it is usually wise.
  • Counterpoint: extensions can interact badly, and specialized systems (time-series, graph, analytics) can be significantly faster or more efficient.
  • Some note Postgres’s 1980s roots and argue that modern, hardware-optimized engines could offer better price/performance, but others emphasize Postgres’s maturity and reliability over cutting-edge optimization.

Managed/cloud Postgres

  • Managed offerings (Google Cloud SQL, AWS-style services, neon.tech) are described as a major quality-of-life improvement: backups, PITR, replication, and metrics “for cheap.”
  • Criticism: some managed services ship very outdated extensions and don’t allow upgrading them.
  • Discussion over whether the future will be standardized Postgres or fragmented, cloud‑specific forks; opinions differ.

SQL Server, licensing, and migration

  • Multiple teams want to move from SQL Server to Postgres due to high licensing costs and RAM/CPU limits.
  • Migrations are hard because of ADO.NET datasets, stored procedures, and T‑SQL differences; Babelfish helps but is not a full drop‑in replacement, especially with heavy stored procedure usage.
  • Debate over “real” nested transactions: some claim SQL Server supports them better; others argue both SQL Server and Postgres essentially rely on savepoints/subtransactions with quirks.

DB‑Engines ranking and methodology

  • Several find the “DBMS of the Year” methodology opaque or inconsistent with the ranking page numbers.
  • Metrics are based on web mentions, jobs, profiles, search results, and social media; many consider this a rough popularity signal but not a serious technical or adoption metric.