The PostgreSQL community supports each major version for five years. After that there are no more bug or security fixes — and on managed services such as Amazon RDS, staying on a version past its standard support period starts adding paid extended-support charges to the bill. PostgreSQL 14 reaches that point in November 2026, which makes this a planning question for a lot of teams right now.
The good news is that major upgrades are well understood. The decision that matters is which method you use, because it determines your downtime, your rollback options and how much work the project is.
Why a major upgrade is different from a minor one
A minor release — 16.4 to 16.6, say — only fixes bugs. You install the new binaries and restart. A major release can change the internal format of the system catalogs, so the existing data directory cannot simply be started by the new version. The data has to be converted or moved, and that is where the two approaches differ.
Option 1: pg_upgrade
pg_upgrade creates a new, empty cluster with the new version and transfers your data into it. It has three relevant modes:
- Copy — copies every data file. Safest, but slow on large databases.
- Link (
--link) — uses hard links instead of copying, so even multi-terabyte databases upgrade in minutes. The trade-off: once the new cluster has been started, the old one can no longer be used safely, so rolling back means restoring from backup. - Clone (
--clone) — on filesystems that support it, gives link-mode speed while leaving the old cluster intact.
Always run pg_upgrade --check first: it reports incompatibilities without changing anything. Two things catch teams out most often. First, every extension you use — PostGIS, TimescaleDB, pg_partman and so on — must be installed and available for the new version. Second, before PostgreSQL 18, pg_upgrade does not carry optimizer statistics over, so the database runs with poor query plans until you run vacuumdb --all --analyze-in-stages. Plan that time into the maintenance window.
Option 2: logical replication
Here you build a new server on the new version next to the old one, replicate the data with native logical replication, let it catch up, and switch the application over. The cutover itself takes seconds, and the old server stays untouched until you decide you no longer need it — which gives you a real rollback path. You can also change hardware, operating system or cloud provider in the same project.
The price is more preparation. Tables need a primary key (or a replica identity) for updates and deletes to replicate. Schema changes are not replicated, so you need a schema freeze during the migration. Sequence values are not replicated either and have to be synchronised at cutover, and large objects need separate handling. We cover the details in our zero-downtime PostgreSQL migration playbook.
Managed databases
On Amazon RDS and Aurora, an in-place major version upgrade uses pg_upgrade under the hood, with the downtime that implies. Blue/green deployments use logical replication to keep a new-version copy in sync and switch over, with the same requirements around primary keys and schema changes. Either way, test the upgrade on a snapshot of production first — the managed service runs the upgrade, but it does not test your application against the new version.
How to choose
- pg_upgrade is the right default when you can schedule a maintenance window of roughly 15–60 minutes and can live with backup-based rollback (or use clone mode).
- Logical replication is worth the extra effort when downtime must be measured in seconds, when the database is large and busy, or when you want to move to new infrastructure at the same time.
In our experience the upgrade mechanism itself rarely causes trouble. The surprises come from around it: an extension that has no build for the new version, a query whose plan changed and got slower, or an application driver that is too old for the new server. All three are cheap to find in testing and expensive to find in production.
The checklist, whichever method you choose
- Read the release notes of every major version you are skipping, looking for incompatibilities.
- Restore a recent production backup on the new version and run your application test suite against it.
- Check that every extension and the application drivers support the new version.
- Compare execution plans and timings of your most expensive queries on old and new versions.
- Take — and verify — a fresh backup immediately before the upgrade.
- Write down the rollback steps and the point after which you will no longer roll back.
Key takeaways
- Each PostgreSQL major version gets five years of support; PostgreSQL 14 reaches end of life in November 2026.
pg_upgradein link or clone mode is fast and simple, but needs a maintenance window.- Logical replication gives cutover in seconds and a real rollback path, at the cost of more preparation.
- Most upgrade problems are extensions, changed query plans and old drivers — test for them first.