Skip to content
dbexplore

Question: Upgrades

Can I skip major versions when upgrading Postgres?

Answered in the first paragraph. Last updated .

Yes. The upgrade tool goes from any release back to 9.2 straight to the current major in a single pass, and doing it in one hop is both faster and less risky than a chain of intermediate upgrades, each of which is another chance to stop halfway. What does not skip is the preparation. Every major version between where you are and where you are going has its own incompatible changes, and all of them land on you at once.

The work that scales with the number of versions skipped

Read the incompatibility section of the release notes for each intervening major, not just the target. Settings are renamed and removed, defaults change, functions and views disappear, and the monitoring queries that break are usually somebody’s dashboard rather than the application.

Extensions are the common blocker. Every extension in every database must exist on the target and be compatible, and the upgrade check refuses rather than proceeding, which is the correct behaviour and is also why the first attempt usually fails on a laptop test. pg_upgrade and extensions covers the inventory to take first.

Then there is the thing that is not a version change at all. A major upgrade usually arrives with a new operating system image, and a change in text collation there reorders text indexes without any warning, which is do I need to reindex after a major upgrade.

When one hop is still too much downtime

The alternative is to build the new cluster alongside, replicate into it logically, and cut over. It costs considerably more setup, and it buys two things the in-place route cannot: the switch is seconds rather than the length of the upgrade, and the old cluster is still there and still current if you need to go back. Physical versus logical replication covers what the logical path can and cannot carry.

There is a trap in the middle of the two routes. Logical replication slots are only preserved by the upgrade tool from PostgreSQL 17 onward, and that support is about upgrading out of 17, not into it. Upgrading a publisher on 14, 15 or 16 destroys its logical slots silently, which means every subscriber needs rebuilding, and nothing in the upgrade output says so.

Whichever route, take a restorable backup first and confirm it restores, because the one thing neither route offers is an undo button.

Put every Postgres you run on autopilot.

We onboard teams in small batches. Tell us about your fleet and we will reach out when a seat opens. One email, no drip campaign.