PostgreSQL 14 End of Life: What It Means and How to Upgrade

PostgreSQL 14 reaches end of life on November 12, 2026 — three days from now. After that date, the PostgreSQL Global Development Group will stop shipping bug fixes and security patches for the entire 14.x line, including the current release, 14.24. Any database still running PostgreSQL 14 after that point keeps working, but it stops receiving official updates, which means new vulnerabilities found in the engine will simply go unpatched for that version.

What "end of life" actually means for PostgreSQL 14

PostgreSQL's own versioning policy is specific about what happens on an end-of-life date: the release team ships one final minor update for the retiring major version, then stops. The 14.24 release notes spell this out directly, stating that "the PostgreSQL community will stop releasing updates for the 14.X release series in November 2026" and encouraging users to move to a newer release branch soon. Nothing about a running PostgreSQL 14 server changes automatically on November 12 — there's no kill switch, no forced shutdown. What changes is support: no more minor releases, no more bundled security fixes, and no more bug fixes, for any 14.x installation, forever.

That matters because PostgreSQL's minor releases are not optional polish. They're the vehicle for every security advisory the project issues for a given major version. Once a version is end of life, any CVE discovered in the PostgreSQL 14 code path — including ones inherited from shared code with still-supported versions — will be fixed in 15 and later, but not backported to 14. A database left on an unsupported major version accumulates unpatched vulnerabilities indefinitely.

PostgreSQL's release and support policy, in brief

PostgreSQL has shipped a new major version roughly once a year since 2010, and each major version gets five years of fixes from its first release. Minor releases land at least quarterly during that window, bundling bug fixes and any necessary security patches; the project also issues out-of-cycle updates for urgent fixes. When the five years are up, the version gets one last minor release and is retired. That cadence is why PostgreSQL 14's clock, started at its September 2021 debut, runs out almost exactly five years later.

The same policy is already playing out one step ahead: PostgreSQL 13 hit end of life on November 13, 2025, a year before 14. And it will repeat for 15 on November 11, 2027, assuming the schedule holds. Knowing this rhythm is useful for planning — if you're budgeting for a PostgreSQL 14 upgrade now, you already know roughly when you'll need to repeat the exercise for whatever version you land on.

That table comes straight from PostgreSQL's own versioning page, which lists every release back to version 6.3. It's worth bookmarking if you manage any PostgreSQL fleet, since it's the canonical source for "is my version still supported" questions.

What actually changes for a database still on PostgreSQL 14

For a self-managed PostgreSQL 14 server, nothing breaks on November 13, 2026. The binaries keep running, queries keep executing, and replication keeps replicating. What stops is the supply of fixes. Concretely, that means:

• No more security patches. Any CVE affecting PostgreSQL's core, found after the 14.24 release, will not get a 14.x fix.
• No more bug fixes. Known issues fixed in 15 and later won't be backported, even quietly.
• No more point releases. There's no "14.25" coming, ever, barring an extraordinary exception the project hasn't signaled.
• Extensions and tooling drift away over time. Driver and extension maintainers generally target supported major versions; testing against 14 will taper off as its install base shrinks.

None of this is an emergency on its own. Plenty of organizations run end-of-life software for a while by choice, usually because an upgrade needs testing or coordination. But every day past the EOL date adds exposure, since there's no safety net if a serious vulnerability turns up.

Managed cloud PostgreSQL: AWS, Azure, Google Cloud, and others

A lot of PostgreSQL 14 workloads live inside managed services rather than on self-run servers, which is why "AWS RDS Postgres 14 end of life," "Azure PostgreSQL 14 end of life," and "Aurora PostgreSQL 14 end of life" are common searches right now. The short version: cloud providers generally run on their own version-support timelines, layered on top of the community's. Amazon's RDS documentation on upgrading the RDS for PostgreSQL engine describes how AWS handles major-version deprecation: it typically intends to keep a major version available at least until the community's own end-of-life date, gives customers an advance window (measured in months) after announcing a deprecation, and then automatically upgrades any instance still left on the old version during a maintenance window.

That pattern — "supported at least through community EOL, with a grace period and then a forced upgrade" — is broadly how the major managed providers approach old PostgreSQL versions, though the exact grace periods, fees for extended support, and automatic-upgrade mechanics differ by vendor and change over time. If you run PostgreSQL 14 on AWS RDS or Aurora, Azure Database for PostgreSQL, or Google Cloud SQL for PostgreSQL, the right move is the same regardless of brand: open that provider's own version-support or lifecycle page for PostgreSQL, confirm the exact date your specific service will stop allowing new 14.x instances or will force an upgrade, and plan around that date rather than assuming it matches the community's November 12 cutoff exactly. Some providers extend a short runway past community EOL; others align tightly with it. Don't guess — check the current page for your account's region and tier.

How to check what version you're actually running

Before planning anything, confirm your current version and minor release. From psql, run:

SELECT version();

or, for just the numeric version:

SHOW server_version;

On a managed service, the console or CLI for your provider will show the engine version directly (for example, the AWS CLI's describe-db-instances call, or the version field in the Azure or Google Cloud consoles). If you manage several databases, it's worth scripting this check across your whole fleet now, since "which of our databases are still on 14" is exactly the question an EOL deadline forces you to answer.

It's also worth checking the minor version, not just the major one. A server showing 14.24 is already on the final release for the series; anything earlier than that — 14.23, 14.18, or older — is missing security fixes the project has already shipped, independent of the bigger end-of-life question. Catching up to 14.24 first, then planning the major-version move, is a reasonable way to split the work if a full upgrade can't happen immediately.

Application code and ORMs are usually the easiest part to check. Most PostgreSQL client drivers and popular ORMs track the wire protocol rather than a specific server version, so they tend to keep working unmodified across a 14-to-17 or 14-to-18 jump. The bigger compatibility risk is almost always server-side: extensions compiled against the old server, custom functions that rely on a deprecated system catalog layout, or configuration flags that were renamed or removed between major versions. The release notes for each version you're skipping over call these out explicitly, which is why reading them — not just the one for your destination version — matters.

How to upgrade off PostgreSQL 14

PostgreSQL's own upgrading documentation lays out three practical paths for a major-version upgrade, since the on-disk format isn't guaranteed compatible across major versions:

• Dump and restore with pg_dumpall. The simplest method: take a logical dump of the old cluster, then load it into a freshly initialized instance of the new version. It's reliable but can mean real downtime on a large database, since the dump and restore both take time proportional to data size.
• pg_upgrade. Migrates the existing data directory in place rather than dumping and reloading every row, which the documentation notes is "much faster" than a dump/restore, especially with its link mode. This is the usual choice for larger production databases.
• Logical replication. Stand up the new major version as a logical-replication target, let it catch up to the running primary, then cut traffic over. This is the lowest-downtime option — potentially just the time it takes to switch connection strings — but it takes more setup and testing than the other two.

Whichever method you choose, the documentation is consistent on a few points: read the release notes (particularly any "migration" or compatibility sections) for every major version you're jumping across, since you can skip versions but should still know what changed in each; test client applications and extensions against the new version before cutting over; and keep your old data directory intact until you've verified the new one, so there's a clean rollback path if something goes wrong.

Where to land: PostgreSQL 15 through 18, or wait for 19

Right now there are four actively supported destinations for a PostgreSQL 14 upgrade: 15, 16, 17, and 18, each with years of support life left on the clock above. Each is a straightforward upgrade target using the same tooling described above — pg_upgrade and logical replication both support jumping more than one major version at once, so you don't have to step through 15 and 16 on your way to 18 if you'd rather go straight there.

PostgreSQL 19, the next major release, is further along in testing — Pandromeda has covered its path from release candidate toward general availability, and more recently reported on its GA date shifting after a second release candidate. For teams specifically timing their PostgreSQL 14 migration against the newest major version, that GA slip is worth factoring in: waiting for 19 to officially ship, rather than upgrading onto a release candidate, is the safer call for anything running production data. If your 14 upgrade can't wait that long, 17 or 18 are both mature, fully supported landing points today.

What to do before November 12, 2026 — and after

If you still have PostgreSQL 14 instances in production, the practical sequence looks like this: inventory every instance and its exact minor version; for self-managed servers, pick pg_upgrade or logical replication based on your downtime tolerance and test it against a staging copy; for managed-cloud instances, check your specific provider's current version-support page for the exact date it will stop supporting or will force-upgrade 14.x, since that date may not line up precisely with the community's; and schedule the actual cutover with enough buffer to roll back if testing turns up a compatibility issue with an extension or client library.

None of this needs to happen in the three days between now and the EOL date itself — a database doesn't stop working on November 12. But every week spent on an unsupported major version afterward is a week without a vendor to call if a vulnerability surfaces in the engine itself. For a database that matters, that's the real deadline: not the calendar date, but the point at which "we'll upgrade soon" stops being a reasonable answer to "are we patched."

Written byFelix Moreau

Felix Moreau writes Pandromeda's software coverage and how-to guides. He covers Windows, macOS and Linux updates, the apps people rely on, emulators and developer tools, and turns official documentation into clear, numbered steps that work on the current version.

More from Felix MoreauAll Software & Guides coverage