PostgreSQL 14 reaches end of life on 12 November 2026

PostgreSQL 14 reaches end of life on 12 November 2026. After that day the PostgreSQL project will not ship another fix for it, not even for a critical security flaw.

If a database in your stack still runs version 14, here is what that means, which version to move to, and how to find every instance.

What end of life means for PostgreSQL

PostgreSQL supports each major version for five years. Version 14 came out on 30 September 2021. Its final minor release is due on 12 November 2026, and after that the community considers it unsupported.

"Unsupported" has a concrete meaning:

• No security patches. A new vulnerability in version 14 stays open.
• No bug fixes, including fixes for data corruption bugs.
• No help from the project when something goes wrong.

Your database does not stop working on 12 November. It keeps running exactly as before. The risk is that from that day, every new flaw found in it stays unfixed.

Which version should you move to?

Do not move to the next version up out of habit. PostgreSQL 15 reaches end of life on 11 November 2027, only a year after 14. You would be back in the same position next autumn.

Pick the newest major version your tools and extensions support. A newer version gives you more years before the next forced upgrade. Check that your extensions (PostGIS, pgvector and so on), your drivers and your ORM all support the target version before you start.

You can see the end-of-life date of every PostgreSQL version on our PostgreSQL page.

How to upgrade

There are three common routes:

1. pg_upgrade. Upgrades the data directory in place. It is fast, especially with its link mode, but you need downtime and a tested rollback.
2. Dump and restore. pg_dump from the old server and restore into a new one. Simple and safe, but slow on large databases.
3. Logical replication. Set up a new server on the new version, replicate until it is caught up, then switch over. The least downtime, the most setup.

Whichever you choose, rehearse it first on a copy of production. Take a backup, and test that the backup restores before you touch anything.

If you use a managed database

Amazon RDS, Google Cloud SQL, Azure and others run their own calendar, and it is not the same as the community date. A provider can retire a version before or after 12 November, and may offer paid extended support after standard support ends.

That brings back the question from end of life vs extended support: which date counts? We plan around the community date. Extended support is time you can buy if the upgrade slips, not a plan. Check your provider's page for the exact date and the price.

How to find every PostgreSQL 14 you run

The database you forgot is the one that bites you. Look in:

• Docker images and Compose files (image: postgres:14).
• Infrastructure as code and Helm charts.
• Cloud consoles, for every account and region.
• Local, staging and test environments that were copied from production.
• Vendor products that bundle their own PostgreSQL.

If your repositories pin a Postgres image or version, the free stack check reads a Dockerfile, package.json, requirements.txt or go.mod and flags versions that are past end of life, with no sign-up.

How StackClock helps

We keep PostgreSQL's end-of-life dates in our catalog. When a workspace has a PostgreSQL runtime or image in its stack, the end-of-life date becomes a deadline on your timeline, with an owner, and we email you 60, 30, 14, 7 and 1 days before. Our public end-of-life calendar for PostgreSQL works with Google Calendar and Outlook if you only want the dates.

Start free, import your stack, and the next version that runs out will not be a surprise.