Near-Zero-Downtime Major Version Upgrades

A major PostgreSQL version jump (e.g. 14 to 17) changes the on-disk catalog format, so the old data directory can't be opened by the new binary directly.

• pg_dump/pg_restore works but locks you out for the full dump+load window — hours on a large database.
• pg_upgrade --link is fast but still requires the application to be fully stopped during the swap, and it operates in place.

Logical replication breaks this trade-off: it streams row-level changes from the old cluster into a freshly initialized new-version cluster while the application keeps writing. Downtime shrinks to a single, planned cutover of a few seconds.

The upgrade runs as a publisher / subscriber pair across versions:

• Publisher = your current production cluster (old version).
• Subscriber = a new cluster running the target major version, initialized empty.

Logical replication is version-independent: it ships decoded logical changes (INSERT/UPDATE/DELETE), not physical WAL pages, so a v14 publisher can feed a v17 subscriber. Once the subscriber is fully caught up and lag is near zero, you flip the application's connection string to the new cluster.