PostgreSQL 14 Reaches End of Life: Time to Upgrade

PostgreSQL 14 reached end of life today. If you run it, this is not a panic moment — it is a planning moment. Here is what changed, what it means for a self-hosted database, and a calm path forward.

What just happened

PostgreSQL 14 shipped on September 30, 2021. Under the project's versioning policy, each major version gets five years of support from its first release, then one final minor release containing any remaining fixes. 14.24 was that final release, and November 12, 2026 marks the end of the line.

From today on, the community ships no new security patches, bug fixes, or updates for the 14 series. If a new security CVE is found in 14 tomorrow, it will not be fixed in the community release.

What "unsupported" actually means for you

You can keep running 14 indefinitely. Nothing forces it to stop, and plenty of self-hosted servers run far older versions. But you now carry the risk yourself. Any newly discovered vulnerability in 14 goes unpatched in the community release — the fix landed in supported versions or nowhere at all.

That is the real cost. A known, unpatched CVE on an internet-facing database is a bad position to sit in, and the window only grows with time.

Two honest options sit in front of you: move to a supported major now, or pay a vendor for extended commercial support of 14. If your organization cannot or will not pay for extended support, the move is the answer.

The supported versions

Right now the supported majors are 15 (until November 2027), 16 (until November 2028), 17 (until November 2029), and 18 (until November 2030). There is no need to climb one rung at a time — pg_upgrade lets you jump from 14 directly to any current major in a single step.

A calm plan for the move

The goal is a boring, rehearsed upgrade: no surprises, no late-night heroics.

Step 1: Find out what you are actually running. Before planning anything, confirm the version on every host.

SELECT version();

You want to see PostgreSQL 14.24 or older on the 14 line. Record which databases, schemas, and extensions live on each server — you will need that list later.

Step 2: Back up first, and verify the backup. Take a full pg_dump (or your usual backup tool) before you touch anything. A backup you have never restored is a hope, not a plan, so spot-check that you can actually read it back.

Step 3: Test on a staging copy. Rehearse the whole upgrade on a throwaway environment that mirrors production: same extensions, same schemas, same queries your apps run. This is where you find the gotchas — not on your production box.

Step 4: Run pg_upgrade on the real server. With a verified backup and a clean staging run behind you, the production upgrade is a checklist item rather than an adventure. pg_upgrade handles the core data migration in one hop from 14 to your target major.

Step 5: Do not forget extensions and configs. The data is only part of it. Reinstall and re-enable any extensions on the new cluster, and re-apply your tuning in postgresql.conf — server settings do not migrate with pg_upgrade. This is the step people skip, and it is where "the upgrade went fine" turns into "why is this slow."

Start this month

You have five years of good behavior to thank, and a clear, documented path to get current. Set a target date, do the staging run, and get yourself onto a major that still receives fixes. Upgrade the database, then sit back — it's a technical move that may hurt slightly for, at most, a weekend, and saves you from chasing security patches that will never arrive.

If you want to track how other long-lived services you depend on are aging while you plan, keep a lifecycle watch over at Tama's infrastructure notes — tama.fdhcl.com.