PostgreSQL 14 End of Life: 12 November 2026, Cloud Deadlines, and What to Upgrade To

PostgreSQL 14 reaches end of life on 12 November 2026. After its final update that day, the PostgreSQL project publishes no more fixes for it, security fixes included. The last regular release before that, on 13 August 2026, fixed 28 security vulnerabilities, three of them rated 8.8, two able to execute code. The next one, in February 2027, won't include version 14. The managed clouds give you a few more months, then charge: AWS RDS moves PostgreSQL 14 to paid Extended Support on 1 March 2027, Google Cloud SQL and Azure on 1 February 2027. If a production database of yours still runs 14, upgrade to PostgreSQL 17 or 18. Version 15 ends in November 2027.

---

When does PostgreSQL 14 end?

On 12 November 2026. The PostgreSQL project supports each major version for five years after its first release, then publishes a final update and stops. From the official versioning page (checked 6 November 2026):

12 November is also the next date on the project's release roadmap, so expect one last 14.x update that day. Install it: it will be the last one. PostgreSQL 19 is at release candidate stage (RC 1 on 15 October 2026) and not yet released.

Is it safe to keep running PostgreSQL 14?

Not as a plan. The August 2026 release (18.6, 17.11, 16.15, 15.19 and 14.24) fixed 28 security vulnerabilities and over 110 bugs. Among them:

• CVE-2026-14664 (CVSS 8.8): a heap buffer overflow in regular expressions that "executes arbitrary code".
• CVE-2026-14669 (CVSS 8.8): a heap buffer overflow in to_char that "executes arbitrary code".
• CVE-2026-14662 (CVSS 8.8): undersized allocations in tsvector and tsquery, through integer wraparound.

That is one quarter's worth. From February 2027, flaws like these get fixed in 15 to 18 and stay open on 14 forever.

How exposed you are depends on who can talk to the database. Most of these flaws need someone able to run SQL: a logged-in user, or an attacker who found a SQL injection in your application. A database that only your own backend reaches, on a private network, can wait a few months. One with an open port, shared logins, or an application nobody has reviewed in years cannot.

PostgreSQL 14 on AWS RDS, Google Cloud SQL and Azure

Managed databases don't stop on 12 November. They keep patching for a few months, then move PostgreSQL 14 into paid extended support, and eventually upgrade you whether you're ready or not.

What it costs. AWS gives a worked rate on its RDS pricing page: $0.100 per vCPU-hour for years 1 and 2 in US East (N. Virginia), on top of the instance. A 2-vCPU database costs about $146 a month extra, a 16-vCPU one about $1,170 a month, and AWS charges more again from year 3. Read replicas count too. Google and Microsoft publish their rates on their pricing pages. Extended support buys security fixes, not new features, and all three providers describe it as a bridge.

On Azure, one more clause. Microsoft's version policy says that "in rare cases where a critical vulnerability in a retired PostgreSQL version poses a threat to the service, Azure might stop affected servers", and that you can't create new servers on a retired version.

Self-hosted (a VM, a Docker image, Kubernetes): nobody moves you and nobody charges you. The Debian, Ubuntu and Red Hat packages follow their own schedules, so check your distribution's security tracker before assuming it still patches 14.

How to check what you run

• In the database: SELECT version(); or SHOW server_version;. psql --version only tells you the client version, which is a common mix-up.
• AWS: aws rds describe-db-instances --query "DBInstances[].[DBInstanceIdentifier,EngineVersion]". Aurora PostgreSQL has its own calendar, check it separately.
• Google Cloud: gcloud sql instances list shows a DATABASE_VERSION column (POSTGRES_14).
• Azure: the portal flags servers nearing end of support; az postgres flexible-server list shows the version.
• Containers: the image: in docker-compose files, Helm values and Kubernetes manifests (postgres:14, postgres:14-alpine), and the database your CI spins up for tests.
• Terraform: engine_version on aws_db_instance, database_version on google_sql_database_instance, version on azurerm_postgresql_flexible_server.

Then list the extensions each database uses (SELECT extname, extversion FROM pg_extension;). Extensions are usually what makes an upgrade slow, not the data.

What to upgrade to

PostgreSQL 17 or 18. 17 is supported until November 2029 and every managed cloud offers it. 18 is supported until November 2030 and is already the default for new Cloud SQL instances. Skip 15: it ends in November 2027. A major upgrade can jump straight from 14 to 18; you don't need to stop at each version.

What usually needs attention on the way from 14:

• Permissions on the public schema. Since PostgreSQL 15, ordinary users can no longer create tables in public by default. An application that creates its own tables at startup, under a non-owner role, can fail on the first deploy after the upgrade.
• Extensions. Core PostgreSQL upgrades, extensions don't always follow. Microsoft's own FAQ puts it simply: non-core extensions such as pgvector or TimescaleDB need ALTER EXTENSION ... UPDATE after the upgrade. Check each one supports the target version first.
• Passwords stored as MD5. PostgreSQL 18 deprecates MD5 password authentication and warns about it. Older roles created with MD5 should move to SCRAM before it is removed.
• Data checksums. PostgreSQL 18 enables data checksums by default on new clusters, and pg_upgrade needs the old and new cluster to match. On a self-hosted upgrade, decide this before you start.
• Query plans. Planner changes across four versions can make one important query slower. Run ANALYZE after the upgrade and compare your slowest queries before and after.

How to do it. On the managed clouds, an in-place major version upgrade is a few clicks, with downtime proportional to the database. AWS offers Blue/Green Deployments to cut that downtime. Self-hosted, pg_upgrade (with --link) is the fast path, pg_dump and pg_restore the simple one for small databases, and logical replication to a new server the way to switch over with minutes of downtime. In every case: restore a copy first, upgrade the copy, run your application's tests against it.

What to do, by situation

What doesn't work is waiting for something to break. Nothing will, on 12 November. It shows up later, as a security fix you can't apply or an extended-support line on the cloud bill.

What we do

We take over applications other teams built, and keep them current. PostgreSQL is our own database: the services we run in production use it, and our main Cloud SQL instance runs PostgreSQL 17, managed in Terraform like the rest of our infrastructure. So on a PostgreSQL upgrade we do the work, not only the plan.

The $2,900 audit reads the code and the infrastructure, lists what is out of support (database, runtime, framework, libraries) and what is exposed, and gives a costed order of work. Then, if you want, we do the upgrade and keep it current, from about $470 a month. For one small tool, our $1,900 starter rebuilds it on hosting we run. Across our own repositories, Dependabot watches dependencies and a scheduled scan re-checks the main branch of every live application. Details on our security page.

What we don't do: we don't sell commercial extended support for PostgreSQL versions, and we won't tell you a database that faces the internet can wait.

Related: Node.js 20 end of life, .NET 8 end of life, Windows Server 2016 end of life, what the CISA KEV list means for your software, taking over abandoned software, and cutting your cloud costs.