PostgreSQL is the Database Management System of the Year 2024

Original Article ↗ Hacker News Discussion ↗

PostgreSQL’s selection as DB-Engines’ “Database Management System of the Year 2024” prompts both praise for its maturity, extensibility, and strong cloud support, and criticism of the ranking methodology, which is based on online mentions rather than real-world deployments. Many engineers argue Postgres is “good enough” for the vast majority of workloads, highlighting features like JSONB, row-level security, and rich extension ecosystems, while noting pain points around built-in high availability, replication management, and major-version upgrades. Others contrast it with systems like MySQL, SQL Server, and specialized analytical or graph databases, debating when Postgres alone is sufficient versus when dedicated or proprietary cloud engines justify their added complexity or lock-in.

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.