PostgreSQL 14 end of life: November 2026
PostgreSQL 14 gets its final update on 12 November 2026. Here is who keeps patching it after that, which version to move to, and how to upgrade with minutes of downtime rather than hours.
- Community support
- Final release 12 Nov 2026, 6 days left
- Amazon RDS
- Standard support to February 2027, then paid Extended Support
- Move to
- PostgreSQL 18 (to Nov 2030), or 19 (to Nov 2031) once settled
- Path
- Straight to the new version: pg_upgrade or logical replication
Does the date affect you?
Run SELECT version(); on each database server, then check where PostgreSQL came from.
From the PostgreSQL apt or yum repository, or a Docker image: these follow the project's date. After 12 November there are no more fixes.
From Ubuntu 22.04's own packages: Canonical keeps patching PostgreSQL 14 while 22.04 is supported, to May 2027. The OS and the database then need moving together.
On Amazon RDS or Aurora: you have until February 2027 before the Extended Support charges start. RDS can do the upgrade for you, but the testing is still yours.
Database servers are seldom open to the internet, so this is less urgent than an end-of-life web server. Auditors and customers' questionnaires ask about it all the same.
18 or 19?
PostgreSQL 18 for upgrades this year. It has been out since September 2025, has had a year of fixes, and is supported to November 2030. Its pg_upgrade also keeps the planner statistics, so queries run at full speed straight after the upgrade.
PostgreSQL 19 if you can wait for it to settle. It is due on 19 November 2026 and buys a year more, to November 2031. Most teams give a new major version two or three update releases before running production on it.
Check your extensions either way. PostGIS, TimescaleDB, pgvector and the rest need builds for the new version, and the newest major is where those can lag.
What changes between 14 and 18
PostgreSQL upgrades are kind to applications. These are the changes that catch people out.
| Version | What changed | What to watch |
|---|---|---|
| 15 | Ordinary users can no longer create tables in the public schema of new databases | An upgraded cluster keeps its old permissions, but databases created on a new server don't. Applications that create their own tables in public fail with "permission denied for schema public" until the owner or grants are fixed. |
| 15 | The old exclusive backup mode was removed | Backup scripts calling pg_start_backup() and pg_stop_backup() break. Use pg_backup_start() and pg_backup_stop(), or a tool such as pgBackRest. |
| 17 | Maintenance commands run with a safe search_path | Functions used in indexes or materialised views that rely on the search path can fail during VACUUM, ANALYZE or REINDEX. Schema-qualify the names inside them. |
| 18 | New clusters have data checksums on by default | pg_upgrade needs the old and new cluster to match, so create the new cluster with --no-data-checksums if the old one has none. |
| 18 | MD5 passwords are deprecated | They still work, with warnings. Move users to SCRAM (password_encryption = scram-sha-256, then reset the passwords), and check old client drivers support it. |
| Any | A change of operating system with the upgrade | A new OS can bring new collation rules, which silently corrupts text indexes. Rebuild them with REINDEX after moving data files across OS versions, or use dump and restore. |
Dates from postgresql.org and AWS's RDS release calendar, read 6 November 2026.
Three ways to upgrade
| Method | Downtime | Good for | Watch out for |
|---|---|---|---|
| pg_upgrade (link mode) | Minutes, whatever the size | Most self-hosted servers. On Debian and Ubuntu, pg_upgradecluster wraps it | Link mode shares the data files, so the old cluster can't be started again afterwards. Take a backup or snapshot first. |
| Logical replication | Seconds, at the switch-over | Large or busy databases, or moving to a new server at the same time | Schema changes and sequences aren't replicated: freeze schema changes during the move and set sequences at the switch. |
| Dump and restore | As long as the dump and restore take | Small databases, and moves across operating systems or architectures | The slowest for large data, but the cleanest result: fresh indexes and no old files carried across. |
Before you upgrade
List the extensions with \dx in each database, and check every one has a build for the new version.
Run the check first. pg_upgrade --check against the new version reports problems without changing anything.
Find old backup scripts and MD5 users. Search for pg_start_backup, and run SELECT rolname FROM pg_authid WHERE rolpassword LIKE 'md5%';.
Rehearse on a copy restored from last night's backup. Time it, and run the application's tests against it.
Afterwards, on versions before 18, run vacuumdb --all --analyze-in-stages so the planner has statistics, then watch the slow query log for a few days.
How I run the move
- 01Inventory and a fixed quote
Every database, its size, extensions and the applications that use it, and which of the changes above will bite. Then a fixed quote.
- 02Rehearsal on staging
A copy upgraded or rebuilt first, every site and job tested, every problem fixed there.
- 03The window, with a way back
The real move at a time you agree, the old server or a snapshot kept ready, then two weeks' stabilisation.
Upgrades and migrations →
Questions
When does PostgreSQL 14 reach end of life?
In November 2026. The update release on 12 November 2026 is its last; after that the PostgreSQL project ships no more fixes for 14.
What about PostgreSQL 14 on Amazon RDS?
RDS standard support for 14 runs to February 2027. After that, instances not upgraded move to RDS Extended Support, charged on top of the instance price, for up to three more years.
Which version should I upgrade to?
PostgreSQL 18, supported to November 2030, for most upgrades today. PostgreSQL 19 is due on 19 November 2026 and will be supported to November 2031; most teams wait for its first couple of update releases before putting production on it.
Can I upgrade straight from 14 to 18?
Yes. pg_upgrade and dump-and-restore both go straight from 14 to any newer major version. There is no need to stop at 15, 16 or 17.
How long will the database be down?
With pg_upgrade in link mode, usually minutes, whatever the size of the data. With logical replication to a new server, only the seconds it takes to switch the application over. A dump and restore takes longest, but is the simplest for small databases.
Is PostgreSQL 14 on Ubuntu 22.04 still patched?
Yes, by Canonical rather than the PostgreSQL project: the package that ships with 22.04 is patched while 22.04 is supported, to May 2027, and to 2032 with Ubuntu Pro. PostgreSQL 14 from the PostgreSQL apt repository follows the project's date and stops in November.
Still on PostgreSQL 14?
Tell me what runs on it. I'll tell you which upgrade method fits, how long the downtime will be, and give you a fixed quote.