PostgreSQL 14 End of Life (November 2026): Upgrade Plan with pg_upgrade or Logical Replication

PostgreSQL 14 reaches end of life on November 12, 2026. Your servers will keep running after that date, but newly discovered security vulnerabilities and bugs will no longer be fixed for version 14. We recommend planning the upgrade now and choosing PostgreSQL 18 as the target.

This guide is written for two readers: the IT managers who make the decision and the technical teams who carry out the upgrade. The first sections summarize what end of life means for the business, how to choose the target version and how the upgrade methods compare. The later sections contain tested steps for pg_upgrade, logical replication and dump/restore. We ran the commands on PostgreSQL 14.24 and 18.6.

At a Glance: PostgreSQL 14 End of Life

What Does End of Life Mean for Your Business?

The PostgreSQL community supports each major version for five years from its first release. For PostgreSQL 14, released on September 30, 2021, that period ends with the final minor release on November 12, 2026.

End of life is not a shutdown date; no server will stop on the morning of November 13. What changes is the maintenance status of the version:

In short, every month on PostgreSQL 14 accumulates risk you can no longer patch away. The earlier the upgrade is planned, the calmer the project runs.

Start with an Inventory: Which Version Are You Running?

Run the two commands below on every server. For comparisons in scripts, server_version_num is more convenient: 140024, for example, means 14.24.

SELECT version();
SHOW server_version_num;

If you run a 14.x release older than 14.24, move to the latest minor release first. A minor update needs no dump or pg_upgrade and lets you start the major upgrade from a system free of known bugs.

Target Version: PostgreSQL 17 or 18?

You can move from 14 directly to either version; there is no need to step through 15 and 16. These are the differences that matter for the decision:

Our recommendation is PostgreSQL 18. It is supported for one more year, and because statistics are transferred, the system returns to normal performance faster after the upgrade. If an extension you use, your application vendor or your cloud provider does not support 18 yet, PostgreSQL 17 is a safe alternative.

We see no reason to wait for PostgreSQL 19. Its first release candidate (RC1) came out on October 15, 2026, and general availability is planned for November 19, 2026. Extensions, drivers and tools usually take a few months to support a new major version.

Whichever target you choose, read the “Migration to Version” section of the release notes for every version you skip. The change that most often surprises applications coming from 14 is in PostgreSQL 15: in new databases, the PUBLIC role can no longer create objects in the public schema. Upgraded databases keep their existing privileges; the difference appears in databases created after the upgrade.

Which Upgrade Method Fits You?

Three questions decide the method: How much downtime is acceptable? Is extra disk or a new server available? How will you roll back if something goes wrong?

In practice the choice usually comes down to this:

• If you are staying on the same server and a few minutes to an hour of downtime is acceptable: pg_upgrade.
• If downtime is limited to minutes or you combine the upgrade with a move to new hardware: logical replication.
• If the database is small and you want to turn the upgrade into a clean-up project: dump/restore.

PostgreSQL 18 also adds the --swap mode. It moves the old data directories into the new cluster and can be the fastest option for clusters with many tables and indexes. As with link mode, it is not safe to start the old cluster once the file transfer has begun.

If You Run on Azure or Amazon RDS

On managed services the provider runs the upgrade, but the schedule and the cost are your responsibility.

Azure runs a precheck before the upgrade and takes an implicit backup to roll back to if it fails. Amazon RDS lists 17.11 and 18.6 as direct targets for PostgreSQL 14.24.

Pre-Upgrade Checklist

The queries below give you the core of the inventory. Run the extension query in every database.

-- Databases, size and collation
SELECT datname, pg_size_pretty(pg_database_size(datname)) AS size, datcollate
FROM pg_database WHERE datallowconn ORDER BY pg_database_size(datname) DESC;
-- Installed extensions (run in every database)
SELECT extname, extversion FROM pg_extension ORDER BY extname;
-- Items pg_upgrade or a cutover cares about
SELECT count(*) AS prepared_xacts FROM pg_prepared_xacts;
SELECT slot_name, slot_type, active FROM pg_replication_slots;
SHOW data_checksums;
-- Roles still using MD5 password hashes
SELECT rolname FROM pg_authid WHERE rolpassword LIKE 'md5%';
-- Tables without a primary key (matter for logical replication)
SELECT c.oid::regclass AS table_without_pk
FROM pg_class c
JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE c.relkind = 'r'
  AND n.nspname NOT IN ('pg_catalog', 'information_schema')
  AND NOT EXISTS (SELECT 1 FROM pg_index i WHERE i.indrelid = c.oid AND i.indisprimary);

Method 1: pg_upgrade from 14 to 18

The examples follow the Debian and Ubuntu package layout of apt.postgresql.org, where each version’s programs live under /usr/lib/postgresql/<version>/bin. Install the PostgreSQL 18 packages alongside 14 and run every command as the postgres user from a directory that user can write to.

1. Create the new cluster

The new cluster must use the same locale and encoding as the old one. One detail matters: PostgreSQL 18 enables data checksums by default, while pg_upgrade requires both clusters to have the same setting. A 14 cluster created with default settings has checksums off, so use --no-data-checksums. Otherwise the check stops with “old cluster does not use data checksums but the new one does”.

OLD=/usr/lib/postgresql/14/bin
NEW=/usr/lib/postgresql/18/bin
cd /var/lib/postgresql/upg
$NEW/initdb -D ../pg18 -U postgres --locale=en_US.UTF-8 -E UTF8 --no-data-checksums

2. Run the compatibility check

The check can run while PostgreSQL 14 is serving traffic. Pass the mode you will use for the real upgrade (such as --link) here as well.

$NEW/pg_upgrade -b $OLD -B $NEW -d ../pg14 -D ../pg18 -p 5414 -P 5418 --check --link

In our test the first check stopped at “Checking for reg* data types in user tables” and wrote the offending column to tables_using_reg.txt under pg_upgrade_output.d. These data types store system identifiers (OIDs) that pg_upgrade cannot preserve. After the column was changed to text on the 14 server, the check finished with “Clusters are compatible”.

3. Stop PostgreSQL 14 and upgrade

$OLD/pg_ctl -D ../pg14 -w stop -m fast
$NEW/pg_upgrade -b $OLD -B $NEW -d ../pg14 -D ../pg18 -p 5414 -P 5418 --link --jobs 2

The run ends with “Upgrade Complete”. If newer extension versions exist, pg_upgrade writes an update_extensions.sql file, and it creates a delete_old_cluster.sh script to remove the old cluster. Do not run that script until the new cluster has passed every check and a fresh backup has been taken.

4. Start PostgreSQL 18 and finish the job

pg_upgrade does not move configuration files. Before pointing applications at the new cluster, carry over pg_hba.conf and the postgresql.conf settings you need. Then start the server, update extensions and create the missing statistics:

$NEW/pg_ctl -D ../pg18 -o "-p 5432" -l ../pg18.log -w start
psql -U postgres -f update_extensions.sql
$NEW/vacuumdb -U postgres --all --analyze-in-stages --missing-stats-only
$NEW/vacuumdb -U postgres --all --analyze-only --jobs 2

In our test PostgreSQL 18 already had the table’s statistics before any ANALYZE had run, and the generated script updated pgcrypto from 1.3 to 1.4. The cluster kept data_checksums = off, as on 14.

If you run standby servers with streaming replication, the pg_upgrade documentation explains step by step how to upgrade them with rsync after the primary. Plan this part with particular care: a mistake here means rebuilding the standbys from scratch.

Method 2: Near-Zero Downtime with Logical Replication

Logical replication copies the data to a new PostgreSQL 18 server and keeps streaming changes until cutover. Because the old server keeps running throughout, downtime is limited to the cutover itself.

Before you start, set wal_level = logical on the 14 server (requires a restart) and allow the replication user in pg_hba.conf.

1. Create a publication on PostgreSQL 14

CREATE ROLE repl_user WITH LOGIN REPLICATION PASSWORD 'change_me';
GRANT SELECT ON orders TO repl_user;
CREATE PUBLICATION upgrade_pub FOR TABLE orders;

Every table in the publication needs a replica identity to replicate UPDATE and DELETE. Tables without a primary key fail on the source with “cannot update table … because it does not have a replica identity and publishes updates”. Add a primary key to these tables; if that is not possible, use ALTER TABLE ... REPLICA IDENTITY FULL as a last resort.

2. Copy roles and schema to PostgreSQL 18

Logical replication does not carry table definitions or DDL; you must move them first. Run the PostgreSQL 18 client tools against the 14 server and replace pg14-host with your own server name.

pg_dumpall -h pg14-host -U postgres --globals-only -f globals.sql
psql -U postgres -f globals.sql
pg_dump -h pg14-host -U postgres -d shop --schema-only --no-publications -f shop_schema.sql
psql -U postgres -d shop -v ON_ERROR_STOP=1 -f shop_schema.sql

A “role “postgres” already exists” error while loading the roles is expected. Investigate any other error.

3. Create a subscription on PostgreSQL 18

CREATE SUBSCRIPTION upgrade_sub
  CONNECTION 'host=pg14-host port=5432 dbname=shop user=repl_user password=change_me'
  PUBLICATION upgrade_pub;
-- 'r' means the initial copy is done and the table is streaming
SELECT srrelid::regclass AS table_name, srsubstate FROM pg_subscription_rel;

The subscription opens a replication slot on the source server. As long as the slot exists, the 14 server keeps the write-ahead log (WAL) for it instead of removing it. Watch the old server’s disk space during the sync.

4. Cut over

Stop application writes on PostgreSQL 14 and confirm that the new server has received every change:

-- On PostgreSQL 14: lag_bytes must be 0
SELECT application_name, state,
       pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS lag_bytes
FROM pg_stat_replication;

Three steps remain on PostgreSQL 18: apply any DDL that changed during the sync, move sequence values forward and drop the subscription. DROP SUBSCRIPTION also removes the slot on the source.

ALTER TABLE orders ADD COLUMN note text;   -- DDL that was added on 14 during the sync
SELECT setval('orders_id_seq', (SELECT max(id) FROM orders));
DROP SUBSCRIPTION upgrade_sub;

Finally, check on the 14 server that SELECT count(*) FROM pg_replication_slots; returns 0. A forgotten slot keeps accumulating WAL until the old server’s disk fills up.

Method 3: pg_dump and pg_restore

This is the simplest method, and it rebuilds every index on the new server. It is a good choice if you can back up and restore the database within the time set aside for maintenance. The PostgreSQL documentation recommends using the pg_dump and pg_dumpall tools of the new version.

pg_dumpall -h pg14-host -U postgres --globals-only -f globals.sql
pg_dump -h pg14-host -U postgres -d shop -Fc -f shop.dump
createdb -U postgres shop_restored
pg_restore -U postgres -d shop_restored --jobs 2 --no-publications --no-subscriptions shop.dump

The custom format (-Fc) allows a parallel restore with --jobs. Unlike logical replication, a dump also carries sequence values. The restored database has no optimizer statistics, so run ANALYZE afterwards.

Collation, glibc and REINDEX

Indexes on text columns depend on the operating system’s sort rules (glibc collation). If the upgrade also moves you to a newer operating system release, rebuild these indexes before going to production. The best-known example of such a change is glibc 2.28.

Not every method is affected in the same way:

• pg_upgrade carries indexes over as they are, so it is affected.
• Dump/restore and logical replication rebuild indexes on the new server, so they are not affected.
• Columns using an ICU collation are not affected by glibc changes.

PostgreSQL 15 and later record each database’s collation version. On the new server you can compare the recorded and actual versions, verify B-tree indexes with amcheck and rebuild the indexes that need it:

SELECT datname, datcollate, datcollversion,
       pg_database_collation_actual_version(oid) AS actual_version
FROM pg_database WHERE datname = 'satis';
-- Structural check of B-tree indexes
CREATE EXTENSION IF NOT EXISTS amcheck;
SELECT c.relname AS index_name, bt_index_check(c.oid, true) AS ok
FROM pg_index i
JOIN pg_class c ON c.oid = i.indexrelid
JOIN pg_am a ON a.oid = c.relam AND a.amname = 'btree'
JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE n.nspname = 'public';
-- Indexes that depend on a collatable column
SELECT DISTINCT ic.relname AS index_name
FROM pg_index i
JOIN pg_class ic ON ic.oid = i.indexrelid
JOIN pg_attribute a ON a.attrelid = i.indrelid AND a.attnum = ANY (i.indkey)
JOIN pg_namespace n ON n.oid = ic.relnamespace
WHERE a.attcollation <> 0 AND n.nspname NOT IN ('pg_catalog', 'information_schema');
-- Rebuild without blocking writes, then record the current collation version
REINDEX INDEX CONCURRENTLY musteri_sehir_idx;
ALTER DATABASE satis REFRESH COLLATION VERSION;

A test result for teams working with Turkish data: in a database created with the tr_TR.UTF-8 locale, lower('IŞIK') and upper('istanbul') returned ışık and İSTANBUL both before and after the upgrade, and the index on the city column stayed in use.

Rollback Plan

Write down the rollback criteria and method before the upgrade. Decisions made under pressure during the work usually make it take longer.

Post-Upgrade Checks

1. SHOW server_version_num; should return a value starting with 18 (180006 for 18.6), and row counts of critical tables should match the source.
2. Compare installed_version and default_version in pg_available_extensions and update extensions that are behind.
3. Make sure statistics exist: run the vacuumdb commands above after pg_upgrade, and ANALYZE after dump/restore and on cloud services.
4. Review settings whose defaults changed: password_encryption, io_method and data_checksums.
5. Run the application tests and watch the server logs and slow queries closely during the first business day.
6. Take a new full backup on PostgreSQL 18 and test the restore. Physical backups and WAL archives taken on 14 cannot be restored with PostgreSQL 18.
7. Clean up temporary resources: old cluster files (after the new backup), replication slots and temporary roles.

When Should You Bring in an Expert?

Upgrading a single small database without extensions is a weekend job. If any of the following applies to you, we recommend working with an experienced team:

• The database is large and the business accepts only a few minutes of downtime.
• You use streaming replicas, a high-availability manager such as Patroni or an existing logical replication setup.
• Extensions such as PostGIS or TimescaleDB, or an application vendor, restrict the target version.
• The upgrade coincides with a new operating system, new hardware or a move to Azure or AWS.
• Nobody on the team has recently rehearsed restoring these databases.

Aryasoft’s senior-only PostgreSQL team plans and runs upgrades end to end: inventory, a rehearsal on a production copy, the cutover itself and the checks that follow. If the upgrade is part of a wider platform change, see our database migration services. If you want regular maintenance once your servers are on 17 or 18, our managed database services, which include a remote DBA service, cover PostgreSQL as well as SQL Server.

Frequently Asked Questions

Sources

The technical details in this guide were checked against the official documentation below in October and November 2026. Dates, versions and cloud policies can change; confirm them on the relevant page before you finalize your plan.

1. PostgreSQL: Versioning Policy
2. PostgreSQL: Roadmap (minor release schedule)
3. PostgreSQL 18 documentation: Upgrading a PostgreSQL Cluster
4. PostgreSQL 18 documentation: pg_upgrade
5. PostgreSQL 18 release notes
6. PostgreSQL 17 release notes
7. PostgreSQL 15 release notes
8. PostgreSQL 18 documentation: vacuumdb
9. PostgreSQL 18 documentation: pg_dump
10. PostgreSQL 18 documentation: Logical replication restrictions
11. PostgreSQL 18 documentation: Logical replication configuration settings
12. PostgreSQL 18 documentation: CREATE SUBSCRIPTION
13. PostgreSQL 18 documentation: Collation Support
14. PostgreSQL Wiki: Locale data changes
15. Microsoft Learn: Major version upgrades in Azure Database for PostgreSQL
16. Microsoft Learn: Azure Database for PostgreSQL extended support
17. Microsoft Learn: Azure Database for PostgreSQL version policy
18. AWS: Amazon RDS for PostgreSQL release calendars
19. AWS: Choosing a major version for an RDS for PostgreSQL upgrade
20. AWS: Amazon RDS Extended Support
21. AWS: Amazon RDS Extended Support charges