PostgreSQL Major Version Policy and Upgrade Planning

PostgreSQL publishes one major version each year, normally in late September or early October, and supports it for five years. Minor releases arrive quarterly and contain only bug and security fixes, never new features. That combination makes PostgreSQL unusually easy to plan around: you know years in advance when a version will fall out of support, and you know that applying a minor update will not change behaviour. This article covers the calendar, the support policy and the practical upgrade routes.

One major version a year

The PostgreSQL Global Development Group has settled into an annual rhythm. Development for a major version runs through a series of commitfests, feature freeze arrives in the spring, beta releases follow over the summer, and general availability lands in late September or early October.

The five-year policy is a commitment from the community, and the end-of-life dates are published years ahead. After the final minor release for a version, no further fixes are produced - including security fixes - so the EOL date is a hard deadline rather than a suggestion.

Minor releases are not feature releases

PostgreSQL minor releases (18.1, 18.2 and so on) are issued roughly quarterly, typically in February, May, August and November, with out-of-band releases when a serious security issue appears.

A minor release never adds features and never changes the on-disk format. Upgrading is simply a matter of installing the new binaries and restarting the server. Occasionally a minor release requires a manual step, such as reindexing after a collation-related fix, and this is always called out prominently in the release notes - which is the one place worth reading before every minor upgrade.

This distinction matters because it removes the usual excuse for postponing patches. There is no compatibility risk in applying a minor update, so there is no reason to run an unpatched server.

Major upgrades: three routes

Major version upgrades do change the on-disk format, so they need planning. There are three practical approaches.

Dump and restore with pg_dump and pg_restore is the simplest and the slowest. Downtime scales with data volume, which makes it suitable for small databases and development environments.

pg_upgrade relinks or copies the data directory in place and is dramatically faster. With --link it uses hard links so that the time taken is largely independent of database size:

pg_upgrade \
  --old-datadir /var/lib/postgresql/17/main \
  --new-datadir /var/lib/postgresql/18/main \
  --old-bindir  /usr/lib/postgresql/17/bin \
  --new-bindir  /usr/lib/postgresql/18/bin \
  --link --check

Run with --check first: it validates the upgrade without touching anything. Note that with --link the old cluster is no longer usable once the new one starts, so a verified backup is essential.

Logical replication gives the shortest downtime. You build a new cluster on the new version, replicate into it while the old one keeps serving traffic, then cut over when replication has caught up. It is the most work to set up and has caveats - sequences and DDL are not replicated automatically - but for systems where a maintenance window is measured in seconds, it is the only realistic option.

After any major upgrade, run ANALYZE across the database. Planner statistics are not carried over by pg_upgrade, and query plans will be poor until they are rebuilt.

What to check before upgrading

• Extensions. PostgreSQL upgrades do not upgrade extensions. Confirm that PostGIS, TimescaleDB, pgvector or whatever else you depend on has a build for the target version before you start.
• Deprecated configuration. Parameters are occasionally removed or renamed; the server will refuse to start with an unknown setting.
• Client library versions. Old client drivers generally work, but authentication defaults have shifted towards scram-sha-256, and very old clients may not support it.
• Replication topology. Physical replicas must be rebuilt or upgraded in the correct order.

Recent direction

Recent major versions have concentrated on performance and operational maturity rather than headline features: improved vacuum behaviour, better query planning, incremental backup support, refinements to logical replication, and I/O subsystem work aimed at getting more out of modern storage. For most installations, the reason to upgrade is not a single feature but the accumulated performance work plus the support window.

Conclusion

PostgreSQL’s release policy is one of its quieter strengths. One major version a year, five years of support, quarterly minor releases that never change behaviour, and end-of-life dates published far in advance. Plan one major upgrade per year or two, apply every minor release promptly, and use pg_upgrade with --check or logical replication depending on how much downtime you can afford.