PostgreSQL 14 end of life: November 12, 2026 and what to do

TL;DR

• PostgreSQL 14 reaches end of life on November 12, 2026, according to endoflife.date. That is days away.
• The line was released on September 30, 2021, and the latest release in it is 14.24.
• After end of life, flaws found in this major release will not get fixes from the PostgreSQL project, so your data layer inherits that risk.
• No exploited vulnerability is tied to this date. This is a planning deadline, not an emergency patch.
• Update to 14.24 now, then schedule the move to a supported major release. Stackurity flags servers still on this line in its daily end-of-life matching.

What reaches end of life, in plain English

PostgreSQL is an open-source relational database. The project publishes a new major release every year and supports each one for a limited number of years. While a major release is supported, the maintainers ship minor releases that fix bugs and security problems. When the support window closes, the release reaches end of life and those minor releases stop for good.

The endoflife.date record for PostgreSQL shows a release date of September 30, 2021 for PostgreSQL 14 and an end of life date of November 12, 2026. It lists no separate extended support period for the line and does not mark it as a long term support release. In practice, November 12, 2026 is a hard stop: there is nothing in the record to lean on afterwards.

The version you see on a server has two parts that matter here. The first number, 14, is the major release, and it decides whether you are covered by the end of life date. The number after the dot is the minor release, which is the patch level inside the line. The latest minor release of PostgreSQL 14 is 14.24.

Why it matters now

Nothing breaks on the day. Your queries keep running and your backups keep working. What changes is what happens the next time someone reports a flaw in the server, its authentication code or one of its bundled tools. For a supported release, a fix appears and you apply a minor update. For a release past end of life, the fix goes to newer major releases only, and you are left to upgrade in a hurry, perhaps while attackers are already trying the flaw.

Databases are also the hardest thing to upgrade quickly. A major upgrade means testing your application against a new version, checking extensions, planning downtime or a replication cutover, and keeping a way back. That is why the deadline matters this week: it is enough time to find every PostgreSQL 14 server and put dates on the upgrades, but not enough to improvise a large migration.

There is also the paperwork. Auditors and customers ask which components are still supported, and a database on an unsupported release becomes a finding that needs an exception, a compensating control or a plan. It is cheaper to have the plan dated before the deadline than to explain afterwards why there was none.

Am I affected?

You are affected if any server, container or managed database service you run uses the PostgreSQL 14 line, in production, staging, a reporting replica or a forgotten test machine. Any version that starts with 14 belongs to the line, up to the latest release, 14.24.

To check one server by hand, connect with a client and ask the server itself:

psql -c "SHOW server_version;"
psql -c "SELECT version();"
postgres --version
pg_lsclusters

The first two commands print the version the running server reports. The third prints the version of the installed binary, which can differ from the running server if a package was updated without a restart. The last one lists clusters on Debian and Ubuntu systems, with their version and status. For a container, run the first command inside it, or read the image tag.

One caveat applies to packages from a Linux distribution: distributions often backport security fixes into the version they ship, so a distribution may keep patching its own PostgreSQL package for a time under its own policy. Do not rely on that. Check the distribution's own support notice for the package you run, and treat the upstream date as the planning deadline.

How to upgrade PostgreSQL 14 before November 12, 2026

1. Make an inventory of every PostgreSQL server and managed database service, with its version, owner and the applications that depend on it. Mark everything that starts with 14.
2. Update each PostgreSQL 14 server to 14.24, the latest release in the line. A minor update keeps the same data directory, so it needs a restart but no dump and restore.
3. Pick the supported major release you will move to, using the PostgreSQL project's own versioning policy page, and read its release notes for incompatible changes and extension requirements.
4. Rehearse on a copy. Restore a recent backup to a test server, run the major upgrade there with the check mode of pg_upgrade first, then run your application's test suite against it.
5. Take a full backup, for example with pg_dumpall, and confirm you can restore it before you touch production.
6. Run the major upgrade in a maintenance window, using pg_upgrade or logical replication to a new server, then rebuild planner statistics and rerun your checks.
7. Confirm the server now reports a supported major release with psql -c "SHOW server_version;", and remove the old cluster only after a safe waiting period.

If the full upgrade cannot land before November 12, 2026, write down the exception with an owner and a date, restrict network access to the server, keep the update to 14.24 in place and track the upgrade. For help ordering work by urgency, see how Stackurity turns findings into upgrade cards.

How to check with Stackurity

Stackurity keeps one live inventory of the software on your servers, container images and managed services. A read-only agent on Linux servers reads installed packages, and AWS managed services such as RDS and Aurora can be connected too. End-of-life data is matched against that inventory every day, so a server on a release line that is about to leave support appears in a short list, most urgent first, next to the vulnerabilities that matter more.

After you upgrade, check again asks the agent for a fresh report and records whether the issue is really gone, so you see the old line disappear instead of assuming the maintenance window worked. Read how verification works. The core is open source, and Stackurity Cloud offers a 14-day free trial without a card: start a free trial.

If you track other platforms that are leaving support, our guides on RHEL 8 end of life and .NET 8 end of life cover the operating system and runtime around your database.

FAQ

When does PostgreSQL 14 reach end of life?

According to endoflife.date, PostgreSQL 14 reaches end of life on November 12, 2026. After that date the PostgreSQL project no longer publishes fixes for this major release, including security fixes.

Is PostgreSQL 14 still getting security updates?

Until November 12, 2026 it is still inside its supported window, and the latest release in the line is 14.24. After that date, treat it as unsupported and expect no new fixes for flaws found later.

What is the latest PostgreSQL 14 release?

The endoflife.date record lists 14.24 as the latest release of the line. If you are on an older minor release, update to it first, since a minor update does not need a dump and restore.

Can I stay on PostgreSQL 14 after November 12, 2026?

The database will keep running, but new vulnerabilities will not be fixed in this major release. If you must stay for a while, record the exception with an owner and a date, keep the server off the public internet and plan the upgrade.

How do I find every PostgreSQL 14 server I run?

Ask each server for its version with the commands above, and check managed database services too. With many servers, an inventory that matches end-of-life dates every day saves you from logging in to each one.

Sources: endoflife.date, PostgreSQL and Stackurity product facts.