PostgreSQL 14 End of Life Explained: How to Upgrade Before 12 November 2026

Nothing breaks on the day, but your database stops getting fixes. PostgreSQL 14 end of life means no more patches after 12 November 2026, so security holes found later stay open.

Think of a phone that no longer gets updates. It still makes calls, but each new flaw stays unfixed on it. Where the picture breaks: a new phone is a quick purchase, but moving a database to a new major version is a project you rehearse.

Picture a common setup. A medicine delivery app keeps its orders, customers and scanned prescriptions in one 220 GB PostgreSQL 14 database. A standby copy can take over if the main server fails. The setup is made up, but the deadline is real.

The team has until 12 November and a quiet window of about 30 minutes at night (made up). This guide follows that team through the choice of a target version and an upgrade path.

You need six words: major version, minor version, cluster, end of life, CVE and downtime.

• Major version: the first number, such as 14 or 18. A new one ships about once a year and may change the system tables, so it needs a real upgrade.
• Minor version: the number after the dot, such as 14.24. It carries only fixes. You install it by swapping the program files, called binaries, and restarting.
• Cluster: one PostgreSQL server and all the databases in its data directory, the folder holding its files.
• End of life (EOL): the point after which a version gets no fixes from the PostgreSQL project.
• CVE: a public ID for one security flaw. Each one usually gets a CVSS severity score from 0 to 10.
• Downtime: the minutes when your app cannot write to the database, because the old server is stopped and the new one is not yet live.

PostgreSQL 14 end of life is 12 November 2026. After one last minor release that day, the project stops fixing version 14.

The project supports each major version for five years after its first release, then ships one final minor release. Version 14 first shipped on 30 September 2021. Minor releases come at least every three months, usually on the second Thursday of February, May, August and November.

Check where your own server stands before planning anything. Connect with psql, the command-line client, and run these lines. We ran them on a fresh 14.24 cluster.

-- Run in psql on the version 14 server
SHOW server_version;   -- 14.24 means you have the August 2026 fixes
SHOW data_checksums;   -- off unless the cluster was made with checksums on
SHOW wal_level;        -- replica is the default; logical replication needs logical
SHOW server_encoding;  -- reuse this and the next two values when you create the 18 cluster
SHOW lc_collate;
SHOW lc_ctype;

On that cluster, which we created with UTF8 and the C locale, they printed 14.24, off, replica, UTF8, C and C. If your server prints an older 14 number, patch it to 14.24 first. That needs new binaries and a restart, plus any extra steps in the release notes of each skipped version.

It misses every security and bug fix released after 12 November 2026. Any flaw found later in code that version 14 shares with newer versions stays open on your server.

The 13 August 2026 update shows the scale. It fixed 28 security flaws and over 110 bugs across the supported versions. The project's security page lists 24 of those flaws as affecting version 14.

Twelve of those 24 were rated 8.8 out of 10. One example is a heap buffer overflow, code writing past the end of a memory area, in regular expressions, the text-pattern feature. It let anyone who can run queries execute code as the operating-system user that runs the database.

Not every flaw is in the server. Two of the 8.8 flaws were in client tools, pg_dump and psql. After 12 November, a new flaw like any of these gets no fix for 14.

Upgrade to PostgreSQL 18 now. It is the newest stable release and is supported until 14 November 2030, four more years of fixes.

As of 19 October 2026, PostgreSQL 19 is not released. RC 1, a release candidate for final testing, came out on 15 October. General release is planned for 19 November, a week after version 14's last fix.

You can jump straight from 14 to 18 without stopping at 15, 16 and 17. The project asks you to read the release notes of every version in between, especially their Migration sections.

Version 15 would be a poor target for the team, because its fixes end on 11 November 2027. The team picks 18 and plans to test 19 next year.

A major upgrade needs one of three methods: dump and restore, pg_upgrade, or logical replication. Copying the data folder to a new version will not work, because the layout of the system tables changes between major versions.

Dump and restore means exporting every database to a file with pg_dumpall and loading it into the new server. Use the dump tools from version 18, which the project recommends.

The team's dump and restore rehearsal took about six hours on staging (made up), so it is out. Both other paths might fit the 30-minute window.

Beginners can stop here: you know the date, the risk, the target and the three paths. The rest is for the engineer running the upgrade, with every command tested on 14.24 and 18.6.

pg_upgrade builds fresh system tables, where PostgreSQL keeps its own records of your tables and users. It reuses your existing data files, because major releases rarely change how table data is stored.

Choosing a transfer mode

The transfer mode decides how data files reach the new cluster. Copy mode, the default, copies every file and leaves the old cluster untouched. It is safe but slow on big databases.

Link mode uses hard links, a second name for the same file on disk, so both clusters share the files and nothing is copied. Swap mode, new in 18, moves the data directories across. The docs say it can beat the others, especially with many tables.

Clone mode uses reflinks, a file-system feature that shares blocks until one side changes them. It is fast and leaves the old cluster untouched. It needs Linux kernel 4.5 or later with Btrfs or reflink-enabled XFS, or macOS with APFS. Link, clone and swap modes also need the old and new data folders on the same file system.

On a file system without reflinks, the check stops you early. On our ext4 test machine, the clone-mode check failed with this line: could not clone file between old and new data directories: Operation not supported. Copy-file-range mode, for Linux and FreeBSD, passed the same check. It can share blocks like clone on some file systems, but on our ext4 disk it still wrote a full copy.

Running the compatibility check first

Run pg_upgrade with the check option first. It changes no data, works while the old server is running, and lists the manual fixes you need. Add your chosen mode so its own checks run too. The script first makes the empty 18 cluster with initdb, the tool that creates a new cluster.

# Run as the operating-system user that owns the data, from a folder it can write to.
# OLD_BIN and NEW_BIN are the bin folders of 14 and 18; OLD_DATA and NEW_DATA are data folders.
# pg_upgrade connects to both servers several times: use peer authentication or a .pgpass file.

# 1. Make the new 18 cluster. Put your old server_encoding and lc_collate in place of UTF8 and C.
#    If lc_ctype differs from lc_collate, use --lc-collate and --lc-ctype instead of --locale.
#    --no-data-checksums matches a 14 cluster where SHOW data_checksums printed off.
"$NEW_BIN/initdb" -D "$NEW_DATA" -E UTF8 --locale=C --no-data-checksums

# 2. Dry run while 14 still serves traffic. Pass the mode you plan to use.
"$NEW_BIN/pg_upgrade" --check --clone \
  --old-bindir="$OLD_BIN" --new-bindir="$NEW_BIN" \
  --old-datadir="$OLD_DATA" --new-datadir="$NEW_DATA" \
  --old-port=5432 --new-port=5433
# Expected last line: *Clusters are compatible*

When the old server is running, the two port numbers must differ, as above. Our run against a live 14.24 server ended with the line Clusters are compatible.

The script assumes a plain install, where initdb puts the config files inside the data folder. If you installed from your Linux distribution's packages, read their upgrade notes first. The docs say packages may ship their own scripts for major upgrades.

The checksum trap in PostgreSQL 18

Data checksums are small codes on each disk page that catch silent corruption. From version 18, initdb turns them on by default. Version 14's initdb left them off by default.

Pause and predict: you make the 18 cluster with plain initdb and run the check against a 14 cluster made the same way. Does it pass?

pg_upgrade needs both clusters to match. With a default 18 cluster and a default 14 cluster, our check stopped with: old cluster does not use data checksums but the new one does.

The fix is to make the new cluster with the no-data-checksums option, as in the script above. If your 14 cluster already has checksums on, leave the option out.

What to do after the upgrade

• Before upgrading, install the version 18 builds of your extensions, such as pg_trgm for medicine-name search. Do not run CREATE EXTENSION again; pg_upgrade carries the definitions over.
• pg_upgrade does not copy pg_hba.conf, which says who may connect, or postgresql.conf, the main settings file. It also skips postgresql.auto.conf, where ALTER SYSTEM commands save settings. In our test, shared_buffers, the main memory cache, fell from 256MB to the default 128MB, and our extra pg_hba.conf line and ALTER SYSTEM setting were gone. The default listen_addresses setting, localhost, makes the server refuse connections from other machines.
• Carry those settings into the 18 data folder before you start it. A 14 setting that 18 no longer has, such as stats_temp_directory, stops 18 from starting.
• The version 18 pg_upgrade carries over most planner statistics, the data summaries the query planner uses. It drops custom ones made with CREATE STATISTICS.
• After the upgrade, run the two vacuumdb lines below. vacuumdb is a command-line tool that runs ANALYZE, the command that rebuilds statistics, on every database.
• Rebuild the standby from the new primary, because the old standby still runs version 14. The docs offer a shortcut with rsync, a file-syncing tool, only for link mode.

# After pg_upgrade finishes, you carry over the config files and start the 18 server
"$NEW_BIN/vacuumdb" --all --analyze-in-stages --missing-stats-only
"$NEW_BIN/vacuumdb" --all --analyze-only
"$NEW_BIN/psql" -Atc "SHOW server_version;"   # expected: 18.6

In our test, a table's ordinary statistics survived the upgrade, but its CREATE STATISTICS data was empty. The first vacuumdb line rebuilt it.

You build a new PostgreSQL 18 server and let it copy every row change from version 14 as it happens. When it has caught up, you point the app at it, and the switch takes seconds.

Logical replication sends row changes, such as a new order, rather than raw disk pages, so it works across major versions. Version 14 publishes the changes, and 18 subscribes to them.

The low downtime has a price. Version 14 needs wal_level, the setting for how much detail goes into its change log, raised to logical. That setting only changes on a restart.

What logical replication never copies

It does not copy the schema, meaning your table definitions, or later schema changes. It does not copy sequence values, the counters behind auto-numbered IDs. It never copies large objects, PostgreSQL's way of storing big files such as scanned images.

We checked this from 14.24 to 18.6. Every row arrived, but the ID sequence on 18 still stood at 1, not 5001. The large object count was 1 on 14 and 0 on 18, with no error. In a second run, the first new order on 18 failed with: duplicate key value violates unique constraint "orders_pkey".

So set every sequence on 18 just before the switch. The docs suggest copying the values from 14 or picking a high enough value from the tables.

Tables without a replica identity

Every published table needs a replica identity, a way to find a row on the other side, usually its primary key. Inserts still work without one. Updates and deletes on that table start failing on the live version 14 server.

Our test update on such a table failed with: cannot update table "audit_log" because it does not have a replica identity and publishes updates. This query lists such tables before you publish anything.

# Needs the psycopg 3 driver: pip install "psycopg[binary]==3.2.10"
import psycopg

# Tables whose UPDATE and DELETE fail once they are in a publication:
# REPLICA IDENTITY NOTHING, DEFAULT with no primary key, or USING INDEX with the index gone.
QUERY = """
SELECT n.nspname, c.relname
FROM pg_class c
JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE c.relkind IN ('r', 'p')
  AND n.nspname NOT IN ('pg_catalog', 'information_schema')
  AND (c.relreplident = 'n'
       OR (c.relreplident = 'd' AND NOT EXISTS (
             SELECT 1 FROM pg_constraint p
             WHERE p.conrelid = c.oid AND p.contype = 'p'))
       OR (c.relreplident = 'i' AND NOT EXISTS (
             SELECT 1 FROM pg_index i
             WHERE i.indrelid = c.oid AND i.indisreplident)))
ORDER BY 1, 2
"""

with psycopg.connect("dbname=orders host=localhost user=postgres") as conn:
    for schema, table in conn.execute(QUERY):
        print(f"Needs a replica identity first: {schema}.{table}")

On our test database it printed three tables: one with no primary key, one set to NOTHING, and one whose identity index was dropped. In the team's database it finds only an audit_log table, easy to fix with a key.

The real blocker is that scanned prescriptions are stored as large objects, which logical replication cannot carry. Moving them into normal tables is a project of its own, and the deadline is too close.

The team picks pg_upgrade in clone mode. Its disks use reflink-enabled XFS (made up), and the new data folder sits on the same volume. The old cluster stays safe as a fallback.

A good plan has a rehearsal, a dated go-live and a written way back. Here is the team's.

1. 1

   Patch and back up

   Move to 14.24 this week. Take a full backup and test that it restores.

2. 2

   Read the release notes

   Read the Migration sections for 15, 16, 17 and 18, noting anything your app relies on.

3. 3

   Rehearse on staging

   Restore the backup to staging, run pg_upgrade with the check option, fix every warning and time the real run.

4. 4

   Test the app on 18

   Run the test suite and the busiest order queries on the upgraded copy.

5. 5

   Schedule the window

   Book a quiet night in early November, before 12 November, and tell everyone who depends on the database.

6. 6

   Upgrade and verify

   Stop the app and the 14 server, then run the same pg_upgrade command without the check option. Carry your pg_hba.conf, postgresql.conf and postgresql.auto.conf settings into the 18 data folder. Start 18, run the vacuumdb lines, check SHOW server_version prints 18.6 and run smoke tests.

7. 7

   Keep the way back open

   Keep the untouched version 14 cluster for now. Rebuild the standby once 18 looks healthy.

On staging, the clone-mode run took 12 minutes and statistics another 8 (made up). That fits the 30-minute window, with the old cluster still safe beside the new one.

Show that you treat an upgrade as a planned change with a way back. Use this frame.

1. 1

   State the deadline and the risk

   Version 14 stops getting fixes on 12 November 2026, so new security flaws stay open.

2. 2

   Pick the target

   Choose the newest stable major version, 18 as of October 2026, for the longest support.

3. 3

   Size the downtime budget

   Ask how many minutes of paused writes the business can accept.

4. 4

   Choose the path

   Dump and restore for small databases, pg_upgrade in a fast mode for minutes, logical replication for seconds if the tables allow it.

5. 5

   Rehearse and keep a way back

   Rehearse on a copy, time it, and keep an untouched old cluster or a tested backup.