Architecture
PostgreSQL 14 End of Life: Your Upgrade Options
PostgreSQL 14 receives its final release in November 2026 and then stops getting security fixes. The three upgrade paths, what breaks most often, and how to move a production cluster to a supported version without a long outage.
By RadixTrie22 September 20263 min read
The PostgreSQL project supports each major version for five years. PostgreSQL 14 was released in September 2021, so its final minor release is scheduled for November 2026, after which it receives no further security or bug fixes. PostgreSQL 14 end of life is therefore not an event to react to in December; it is a deadline that decides what your production clusters should be running by the northern autumn. This article explains what changes, the three ways to upgrade, the things that most often go wrong, and how to sequence the work for a cluster that cannot be down for long.
What end of life means for a PostgreSQL major version
Nothing stops working on the day. The cluster starts, queries run, backups complete. What stops is the supply of fixes: any vulnerability found after the final release stays open, and the extensions and drivers around PostgreSQL gradually drop the version from their test matrices. PostgreSQL 13 reached the same point in November 2025. At the time of writing, the supported majors are 15, 16, 17 and 18, each with its own end date roughly five years after release, and the project normally ships a new major every autumn. If you are on 14, a move to a recent major buys the longest runway for a single project.
The three upgrade paths
- pg_upgrade. The in-place tool that converts the data directory to the new version, usually in minutes with link mode, so downtime is short. It needs the new binaries installed alongside the old ones, a compatible set of extensions on the target, and a full backup you have actually restore-tested first, because it is not reversible once the old cluster is modified. On versions up to 17 it does not carry planner statistics across, so the first hours after the upgrade need an ANALYZE run or performance will look worse than it is.
- Logical replication. Stand up the new cluster on the target version, replicate the tables into it while the old one keeps serving, then switch the application over when the two are in step. Downtime is measured in the time it takes to repoint connections. It costs more setup, sequences and DDL need handling separately, and large tables take time to copy, but it is the route for clusters where an hour of downtime is not available and the rollback must be trivial.
- Dump and restore. pg_dumpall or pg_dump followed by a restore into the new cluster. The simplest path and the one with the longest outage, proportional to the size of the data. Appropriate for smaller databases, for consolidating several old clusters into one, or when the operating system and hardware are being replaced at the same time.
What breaks most often
Extensions first. PostGIS, TimescaleDB, pg_partman, pg_cron and the rest each need a version that supports the target major, and some require their own upgrade step after PostgreSQL moves. Check every extension in every database before choosing a target version. Second, collations: if the operating system or its C library changes as part of the move, text indexes built under the old collation can silently return wrong results until they are rebuilt, so plan a REINDEX where the platform changes. Third, drivers and ORMs pinned to an old protocol or to removed server behaviour; run the real application against a copy on the new version rather than trusting release notes. Fourth, the performance surprise described above when statistics are missing after pg_upgrade. Finally, managed services: cloud providers set their own deprecation schedules for major versions, often ahead of the community date, and may force an upgrade window on you if you do not choose one.
The one habit that prevents nearly every upgrade incident is rehearsal: restore a recent backup onto the target version, run the application and the heaviest reports against it, time the cutover, and practise the rollback before touching production.
A plan that fits a production cluster
Inventory every PostgreSQL 14 cluster with its size, extensions, replication topology and the applications that connect to it. Choose one target major for the estate unless something forces an exception. Pick the upgrade path per cluster from the downtime you can afford, not from habit: pg_upgrade for most, logical replication for the ones that cannot stop, dump and restore for the small or the consolidating. Rehearse on a copy, fix what breaks, then schedule production with the rollback written down. Afterwards, refresh statistics, watch the slow-query log for a week, and confirm backups and replicas are healthy on the new version before decommissioning the old one.
This is bread-and-butter work for a senior PostgreSQL DBA and a distraction for everyone else. Our remote DBA services cover exactly this: senior engineers who plan and run PostgreSQL upgrades remotely for organisations wherever they are, and who can stay on afterwards to run the cluster under a fixed monthly retainer. If the reason you are on PostgreSQL at all is a move away from Oracle, our guide to Oracle to PostgreSQL migration covers that road, and database high availability and disaster recovery explains how to make the upgraded cluster resilient. Every one of our database services is delivered by the engineer who does the work, with no service desk in between.
TAGSPostgreSQLPostgreSQL 14UpgradeEnd of Life