Why does everyone run ancient Postgres versions?

Original Article ↗ Hacker News Discussion ↗

Many engineers are sticking with PostgreSQL versions that are years behind the latest release, not because they lack features, but because major upgrades are risky, operationally complex, and often provide little perceived benefit for stable systems. Commenters compare Postgres with MySQL, MariaDB, MongoDB, and SQL Server on reliability, replication, transactional guarantees, and ease of administration, arguing that Postgres favors correctness and extensibility at the cost of harder upgrades and more operational care. A recurring theme is that databases are "sticky" infrastructure: without a strong security, support, or feature-driven reason to upgrade—and without first-class tooling for near-zero‑downtime migrations—organizations tend to leave well‑running installations alone for as long as possible.

Why many run “ancient” Postgres versions

  • Main theme: upgrading DBs is high‑risk, high‑effort, and offers little visible payoff if things already work.
  • Databases are central and stateful; failures mean data loss or long outages, so teams avoid touching them unless forced (security, EOL, new must‑have feature).
  • Regression testing across all dependent apps is expensive; many orgs won’t prioritize it over feature work.

Technical upgrade pain points

  • Major versions require pg_upgrade or dump/restore; format changes every year are seen as a “design fail” by some.
  • Upgrades often mean planned downtime; true zero‑downtime is complex even with replication and logical replication.
  • Logical replication helps with blue/green upgrades but:
    • Doesn’t cover all features (e.g., large objects, some DDL).
    • Requires manual schema sync and coordination with CDC systems.
  • Admin complaints: vacuum tuning, txid wraparound, index fragmentation, pg_hba.conf complexity, multiple versioned packages left around on Debian/Ubuntu.

Postgres vs MySQL/MariaDB and others

  • Pro‑Postgres arguments:
    • Transactional DDL, richer SQL and data types, good docs, extensions (PostGIS, LTREE), predictable behavior, UTF‑8 done “right”.
    • Perceived as correctness‑ and stability‑first, “boring” in a good way; no Oracle licensing baggage.
  • Pro‑MySQL/MariaDB arguments:
    • Easier replication, HA, and upgrades; fewer knobs like vacuum; “just works” feeling.
    • Galera‑style multi‑master and online OPTIMIZE TABLE praised.
  • Counterpoints:
    • MySQL’s history of data‑loss footguns, non‑transactional DDL, charset mess, Jepsen‑found anomalies.
    • Some DBAs say Postgres is actually easier to keep reliable; others say the opposite.

Security, support, and version age

  • Several note that Postgres supports each major for ~5 years; distros (e.g., Debian/Ubuntu, RHEL) pin a version for an OS release and backport security fixes.
  • Some only upgrade for security patches or when versions go EOL; others argue that infrequent big upgrades are riskier than regular small ones.

Culture, tooling, and hosting

  • Strong “if it ain’t broke, don’t fix it” and fear of being blamed for breaking prod.
  • Managed services (RDS, Aurora, Heroku, Neon) make minor/major upgrades much easier via blue‑green or auto‑upgrade, and some teams lean on that.
  • A minority actively practice frequent upgrades (often weekly) and report smooth Postgres 16→17 moves; others are still on 9.x or older.