Upgrade PostgreSQL 14 Before 12 November 2026: pg_upgrade vs Logical Replication

The short answer

PostgreSQL 14's final release is scheduled for 12 November 2026, according to the PostgreSQL versioning policy. The current minor is 14.24. After that date, no further fixes ship for 14. Upgrade to PostgreSQL 18 (current minor 18.6, supported until 14 November 2030) or PostgreSQL 17 (supported until 8 November 2029).

Choose the method by how much downtime you can take:

• pg_upgrade with --link upgrades in place. Downtime is roughly the time to move the system catalogs, usually minutes, and it does not grow with data size. Rollback is limited once the new server starts.
• Logical replication copies data to a new 17 or 18 cluster while 14 keeps serving, then cuts over in seconds. It takes longer to set up and has restrictions on DDL, sequences and large objects.

On Amazon RDS and Aurora, standard support for 14 runs until 28 February 2027, and Extended Support charges start on 1 March 2027. You have a little longer there, at a cost.

This post is specific to PostgreSQL 14 and its deadline. For the general method comparison across versions, see our PostgreSQL major version upgrade guide.

Why not PostgreSQL 19?

As of 5 October 2026 it has not been released. PostgreSQL 19 Beta 4 shipped on 24 September 2026, and the announcement says a release candidate should follow in early October and that general availability "may also occur in October". An upgrade forced by a November deadline should not depend on a version that has not shipped. Upgrade to 18 now and plan 19 for later.

17 or 18?

Both 17 and 18 can carry logical replication slots through a future pg_upgrade, a feature that only works when the old cluster is 17 or later. That makes the next upgrade easier whichever one you pick. Unless an extension you depend on lacks an 18 build, choose 18.

Breaking changes between 14 and 18

Extensions

Every extension must be installed for the new major version before pg_upgrade runs, and pg_upgrade --check reports any that are missing. List what you have with SELECT extname, extversion FROM pg_extension; in every database, then confirm each one supports 17 or 18 at the version you will install. After the upgrade, run ALTER EXTENSION ... UPDATE where a newer extension version is available. PostGIS, pg_partman and TimescaleDB each publish their own upgrade notes, so read them before you plan the window.

Method 1: pg_upgrade with --link

1. Install the PostgreSQL 18 binaries next to 14.
2. Check the old cluster: SHOW data_checksums;, encoding and locale.
3. Run initdb for 18 with the same encoding and locale, adding --no-data-checksums if 14 has checksums off. Port postgresql.conf and pg_hba.conf, dropping removed settings.
4. Run pg_upgrade --check --link with the old and new bindir and datadir. It leaves the old cluster untouched. Fix everything it reports.
5. Take a backup you have tested restoring.
6. Stop applications and the 14 server. Run pg_upgrade --link --jobs=<n>.
7. Start 18. Run vacuumdb --all --analyze-in-stages --missing-stats-only, then vacuumdb --all --analyze-only, as the pg_upgrade documentation directs. On 17, run vacuumdb --all --analyze-in-stages instead.
8. Upgrade streaming standbys with the rsync procedure in the pg_upgrade documentation, or rebuild them from the new primary.

--swap on 18 can be faster than --link on clusters with many relations, but the old cluster is destructively modified as soon as file transfer begins. If you want any chance of going back without a restore, use --link or a copy mode.

Method 2: logical replication cutover

1. Set wal_level = logical on 14 (this needs a restart) and make sure every replicated table has a primary key or a replica identity.
2. Build the 18 cluster and load the schema with pg_dump --schema-only from 14, plus roles from pg_dumpall --roles-only.
3. On 14, run CREATE PUBLICATION upgrade_pub FOR ALL TABLES; in each database.
4. On 18, run CREATE SUBSCRIPTION upgrade_sub CONNECTION '...' PUBLICATION upgrade_pub;. The initial copy runs while 14 keeps serving.
5. Watch pg_stat_subscription on 18 and the replication slot lag on 14 until the copy finishes and lag stays near zero.
6. Freeze DDL from here on. Schema changes are not replicated.
7. At cutover: stop writes to 14, wait for lag to reach zero, copy sequence values across (read last_value from pg_sequences on 14 and call setval() on 18), then repoint applications.
8. For a rollback path, create a publication on 18 and a subscription on 14 with copy_data = false before you open 18 to writes, so 14 keeps receiving changes.

The restrictions come from the PostgreSQL documentation: DDL is not replicated, sequence data is not replicated (the subscriber's sequences stay at their start values), large objects are not replicated, and only tables can be published, not views or materialized views. If you rely on large objects, logical replication will not move them.

Amazon RDS and Aurora

Both RDS for PostgreSQL 14 and Aurora PostgreSQL 14 stay on standard support until 28 February 2027. From 1 March 2027 they move into paid Extended Support, which ends on 28 February 2030. Two upgrade routes are available:

• In-place major version upgrade, which runs pg_upgrade for you, with the same downtime profile as Method 1.
• Blue/green deployment, which uses logical replication when the green environment runs a higher major version. AWS documents the same restrictions as native logical replication, plus some of its own: a DDL change on blue puts green into "Replication degraded" and you must recreate the deployment; large object changes do the same; tables without a primary key cannot take UPDATE or DELETE; pg_partman must be disabled; and point-in-time recovery history does not carry over to the new production instance. Sequences are synced at switchover.

For what staying on 14 costs, see OSSeva vs AWS RDS Extended Support and the cost of RDS Extended Support for PostgreSQL.

Test plan

• Run pg_upgrade --check against a production-sized copy and time a full upgrade there.
• Run the application's test suite against 18, with production-like data.
• Capture the slowest and most frequent queries from pg_stat_statements on 14 and compare plans and timings on 18.
• Run REINDEX and VACUUM on staging to catch the search_path change in 17.
• Check that backups, WAL archiving, monitoring queries, connection poolers and HA tooling (Patroni, repmgr) work against 18.
• For logical replication, compare row counts per table and checksums of key tables between 14 and 18 before cutover.
• Restore a backup of the upgraded cluster to prove the new backup chain works.

Rollback plan

• pg_upgrade with --check or a copy mode: the old cluster is unmodified and can be restarted.
• pg_upgrade with --link, new server never started: remove the .old suffix from global/pg_control in the old data directory and restart 14.
• pg_upgrade with --link after 18 has started, or with --swap: the old cluster is not safe to use. Rollback means restoring the pre-upgrade backup and losing writes since.
• Logical replication: if you set up reverse replication, point applications back to 14, which has every write. Without it, 14 is missing everything written after cutover.
• RDS blue/green: the old blue instance keeps its own backups and PITR history after switchover. Keep it until you no longer need to go back.

If you cannot upgrade by 12 November

Some databases cannot move in time, because of an extension with no 17 or 18 build, a vendor application certified only on 14, or a change freeze over the end of the year. OSSeva keeps PostgreSQL 14 patched after community end of life with signed builds that backport security fixes, VEX attestation for scanner findings, and 24/7 DBA operations on the Operate tier, so the upgrade can happen on a schedule you choose. See PostgreSQL support, the PostgreSQL 14 end-of-life page, the PostgreSQL end-of-life tracker, and what happens to PostgreSQL security after end of life.

Common questions

Can pg_upgrade go from 14 straight to 18?

Yes. pg_upgrade supports upgrading across several major versions in one step, so there is no need to stop at 15, 16 or 17.

Will PostgreSQL 14 stop working on 12 November 2026?

No. It keeps running. That date is the last community release, so any vulnerability found afterwards gets no community fix for 14.

Does pg_upgrade from 14 keep logical replication slots?

No. Slot migration in pg_upgrade only works when the old cluster is 17 or later. Recreate slots and subscriptions after upgrading from 14.