PostgreSQL supports each major version for five years. For PostgreSQL 14, first released in September 2021, that window closes on 12 November 2026, when the final minor release ships. After that date, any new security vulnerability stays unpatched. If your analytics database, application backend or data warehouse staging area still runs 14, now is the time to plan the move. This guide covers which version to choose, how to upgrade, and what can break.
How long each version is supported
End of support dates from the PostgreSQL versioning policy: 14 (12 Nov 2026), 15 (11 Nov 2027), 16 (9 Nov 2028), 17 (8 Nov 2029), 18 (14 Nov 2030).
Which version should you move to?
PostgreSQL 18
Recommended- Supported until
- Nov 2030
- Longest support of any released version
- Asynchronous I/O, skip scans,
uuidv7(), OAuth login pg_upgradekeeps planner statistics- Some extensions may lag behind
The default choice for most upgrades.
PostgreSQL 17
Safe fallback- Supported until
- Nov 2029
- Mature, widely certified by vendors
- Fewer behaviour changes than 18
- One year less support than 18
Use it if a vendor or extension is not certified for 18 yet.
PostgreSQL 19
Too new- Status
- due October 2026
- REPACK CONCURRENTLY, parallel autovacuum
- Brand new; extensions and tools need time
- Not worth the risk against a November deadline
Move to 18 now, consider 19 next year.
Three ways to upgrade
pg_upgrade
Most common- Downtime
- minutes
- Effort
- low
- Fast with
--linkor the new--swapmode - No need to copy data
- Both versions on the same host, with matching extensions
- Link and swap modes make the old cluster unusable afterwards
Logical replication
Least downtime- Downtime
- seconds
- Effort
- high
- Switch over when you are ready
- Old cluster stays intact as a fallback
- Needs primary keys and
wal_level = logical - Schema changes, sequences and large objects are not replicated
Dump and restore
Simplest- Downtime
- grows with size
- Effort
- low
- Works across servers and operating systems
- Old cluster is untouched
- Hours of downtime for large databases
Best for small databases or a full server move.
Step 1: check what you have
Run these on the old server before planning anything. They answer the questions that most often derail an upgrade:
-- Exact version
SELECT version();
-- Extensions you will need on the new server, at matching versions
SELECT extname, extversion FROM pg_extension ORDER BY 1;
-- Are data checksums on? (They are on by default in PostgreSQL 18)
SHOW data_checksums;
-- Users still on MD5 passwords, deprecated in PostgreSQL 18
SELECT rolname FROM pg_authid WHERE rolpassword LIKE 'md5%';
-- Database sizes, to estimate how long a dump would take
SELECT datname, pg_size_pretty(pg_database_size(datname)) FROM pg_database;Step 2: upgrade
# Paths are typical for Linux packages; adjust to your install.
# 1. Install PostgreSQL 18 and the same extensions, then create the new cluster
# with the same encoding, locale and checksum setting as the old one.
# 2. Dry run: checks compatibility, the old server can keep running
/usr/lib/postgresql/18/bin/pg_upgrade \
--old-bindir=/usr/lib/postgresql/14/bin \
--new-bindir=/usr/lib/postgresql/18/bin \
--old-datadir=/var/lib/postgresql/14/main \
--new-datadir=/var/lib/postgresql/18/main \
--check
# 3. Stop PostgreSQL 14, then run the same command without --check
# and with --link (or --swap) for minutes of downtime.
# 4. Start PostgreSQL 18 and rebuild missing statistics
vacuumdb --all --analyze-in-stages --missing-stats-only-- On the PostgreSQL 14 server (wal_level must be 'logical')
CREATE PUBLICATION upgrade_pub FOR ALL TABLES;
-- On the new PostgreSQL 18 server, after restoring the schema only
-- (pg_dump --schema-only on 14, then load it into 18)
CREATE SUBSCRIPTION upgrade_sub
CONNECTION 'host=old-db dbname=analytics user=replicator'
PUBLICATION upgrade_pub;
-- When the data has caught up: stop writes on 14, copy sequence
-- values across, point applications at 18, then drop the subscription.# Custom format with parallel restore
pg_dump -Fc -d analytics -f analytics.dump # run against 14
createdb -h new-server analytics # on 18
pg_restore -h new-server -d analytics -j 4 analytics.dumpWhat changes between 14 and 18
Breaking changes to check
- Public schema permissions (15)
- New databases no longer let every user create objects in the
publicschema. Grant it explicitly if your tools rely on it. - Backup functions (15)
- Exclusive backup mode was removed and the backup functions renamed. Old backup scripts may fail.
- MD5 passwords (18)
- Deprecated. Move users to SCRAM-SHA-256 and update
pg_hba.conf. - VACUUM and ANALYZE (18)
- Now process child tables of partitioned tables by default.
- COPY FROM CSV (18)
- No longer treats
\.as end of file. - Full text search (18)
- Uses the cluster's default collation provider, so full text and
pg_trgmindexes may need rebuilding.
The upgrade checklist
- 1
List every instance
Version, size, operating system, replicas and who owns it. Do not forget test and reporting copies.
- 2
Confirm extensions and drivers
Every extension must exist on 18 at a compatible version; check application drivers and BI connectors too.
- 3
Take and test a backup
A backup you have not restored is a hope, not a plan.
- 4
Rehearse on a copy
Run the full upgrade on a copy of production and time it.
- 5
Plan replicas
Physical standbys cannot span major versions and must be rebuilt.
- 6
Upgrade and rebuild statistics
Run
vacuumdbstraight after, then compare query plans for your slowest reports. - 7
Keep a way back
Know exactly how you would return to 14 if something goes wrong.
Check your understanding
1/3What happens to PostgreSQL 14 after 12 November 2026?
It keeps running, but any newly found vulnerability stays unpatched.
2/3Which upgrade method gives the shortest downtime?
You replicate into the new version while the old one runs, then switch over in seconds.
3/3Why might pg_upgrade refuse to run when moving from 14 to 18?
Checksums are on by default in 18; both clusters must match.
You got 0 out of 3.
Curious what comes next? Read PostgreSQL 19: what's coming, and if you are deciding between databases, How to choose a database.
Sources: the PostgreSQL versioning policy and release announcements; WZ-IT's PostgreSQL 14 end-of-life upgrade guide; PostgreSQL 15 to 18 release notes. Always read the release notes for every version you skip.
Alessandro Ecclesie AgazziWritten by Alessandro Ecclesie Agazzi, analytics engineer in London. Updated 21 October 2026. About me