Why does everyone run ancient Postgres versions?

Original Article ↗ Hacker News Discussion ↗

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.