PostgreSQL EOL Dates: Every Version's Release & End-of-Life Timeline

PostgreSQL is the most-loved relational database in the industry and one of the most widely deployed, powering everything from single-tenant SaaS backends to multi-petabyte analytics fleets at Apple, Instagram, and Spotify. It also moves on a strict, predictable lifecycle: a new major version ships roughly once a year, and each major version is supported for exactly five years before it goes end-of-life (EOL).

For engineering and platform teams, that predictability has two sides. The schedule is easy to plan around, but major version upgrades are rarely trivial. They involve pg_upgrade or logical replication cutover, extension compatibility checks, planner regression testing, and a maintenance window on a stateful system that holds your production data. The result is that a large share of running PostgreSQL instances sit on versions that are already EOL or within a year of it.

This guide is the definitive reference for every PostgreSQL major version, its release date, its EOL date, the CVEs that affect older releases, and what your options are once the community stops shipping patches.

‍

How PostgreSQL's Support Policy Works

The PostgreSQL Global Development Group (PGDG) follows one of the clearest support policies in open source:

• Major version cadence: A new major version with new features ships approximately once per year. Since PostgreSQL 10, the major version is the first number (e.g., 14 to 15). Before 10, it was the first two numbers (e.g., 9.5 to 9.6).
• Minor releases: Each supported major version receives bug fixes and security fixes in minor releases at least once every three months. Minor releases never contain new features and never break on-disk compatibility, so applying them is low-risk. Out-of-band releases ship when a critical fix cannot wait.
• Five-year support window: PGDG supports each major version for five years from its initial release. After the five-year anniversary, the version receives one final minor release containing any remaining fixes, and is then considered EOL and unsupported.

There is no "LTS" tier in PostgreSQL. Every major version gets the same five years, and after that the community ships nothing: no security patches, no bug fixes, no compatibility updates. PGDG's own guidance is to always run the latest available minor release for whatever major version you are on.

‍

Complete PostgreSQL Version Timeline

The table below covers every actively relevant major version. Versions currently supported are marked Supported; versions past their five-year window are marked EOL.

Everything from PostgreSQL 9.3 and earlier has been EOL for more than seven years and should be treated as critically exposed.

‍

Versions Reaching EOL Next: What to Watch

PostgreSQL 14 End of Life: November 12, 2026

PostgreSQL 14 was released on September 30, 2021, which puts its five-year EOL date at November 12, 2026. After that date, version 14 receives its final minor release (14.23 is the current latest) and then stops receiving any community patches.

PostgreSQL 14 is the version most platform teams should be watching right now. It is still extremely common in production, particularly on managed services where major-version upgrades were deferred, and its EOL is now inside the next-minor-release horizon. If a critical vulnerability is disclosed after November 12, 2026, the PostgreSQL community will not ship a fix for version 14.

PostgreSQL 13 End of Life: November 13, 2025

PostgreSQL 13 reached EOL on November 13, 2025. Its final minor release, 13.23, shipped on November 10, 2025. Any vulnerability disclosed against version 13 after that date is permanently unpatched in the community distribution. Teams still on 13 are now running an unsupported database engine.

PostgreSQL 12 End of Life: November 21, 2024

PostgreSQL 12 reached EOL on November 21, 2024, with 12.22 as its final community release. Version 12 has now been unsupported for over a year and a half, and managed providers have begun force-upgrading or charging extended-support fees for instances still running it.

‍

CVEs Affecting PostgreSQL 14 and Earlier

PostgreSQL's security record is strong, but "strong" does not mean "no CVEs." Several high-impact vulnerabilities have been disclosed recently, and the pattern matters: the same flaws routinely affect every supported branch at once, including 14 and 13. Once a branch goes EOL, the next disclosure in this pattern simply goes unpatched for that branch.

CVE-2025-1094 (CVSS 8.1): psql SQL Injection

The most significant recent PostgreSQL vulnerability. CVE-2025-1094 is a high-severity SQL injection flaw caused by improper neutralization of quoting syntax in libpq's escaping functions (PQescapeLiteral(), PQescapeIdentifier(), PQescapeString(), and PQescapeStringConn()) and in the psql interactive terminal. Under specific encoding conditions, an attacker can break out of escaping and inject SQL, and via psql meta-commands like \!, escalate to arbitrary OS command execution.

It was discovered by Rapid7 during analysis of the BeyondTrust breach tied to CVE-2024-12356, and was implicated in real-world exploitation against high-profile targets before it was patched.

• Affected: All versions before 17.3, 16.7, 15.11, 14.16, and 13.19
• Fixed in: 17.3, 16.7, 15.11, 14.16, 13.19 (released February 13, 2025)

CVE-2025-8714 (CVSS 8.8): pg_dump Restore-Time Code Injection

A malicious superuser on an origin server can craft object names containing psql meta-commands that execute as the OS account running a restore. The flaw spans pg_dump, pg_dumpall, and pg_restore when generating plain-format dumps.

• Affected: All versions before 17.6, 16.10, 15.14, 14.19, and 13.22
• Fixed in: 17.6, 16.10, 15.14, 14.19, 13.22 (released August 14, 2025)

CVE-2025-8715 (CVSS 8.8): pg_dump Newline Injection with SQL Injection on Restore Target

A closely related flaw disclosed in the same August 14, 2025 batch. Improper neutralization of newlines in object names lets a user of the origin server inject arbitrary code for restore-time execution as the OS account running psql, and the same attack can achieve SQL injection as a superuser on the restore target server. pg_dumpall, pg_restore, and pg_upgrade are also affected.

• Affected: All versions before 17.6, 16.10, 15.14, 14.19, and 13.22 (versions before 11.20 are unaffected)
• Fixed in: 17.6, 16.10, 15.14, 14.19, 13.22 (released August 14, 2025)

CVE-2025-8713 (CVSS 3.1): Optimizer Statistics Disclosure

A lower-severity but instructive flaw: a crafted "leaky" operator can bypass view ACLs and row-level security policies via the optimizer statistics system, exposing histogram and most-common-values data the querying user should not see. It is a recurrence of a class of issue that CVE-2017-7484 and CVE-2019-10130 were intended to close.

• Affected: All versions before 17.6, 16.10, 15.14, 14.19, and 13.22
• Fixed in: 17.6, 16.10, 15.14, 14.19, 13.22 (released August 14, 2025)

CVE-2025-4207 (CVSS 5.9): GB18030 Buffer Over-Read

A buffer over-read in GB18030 encoding validation allows a database input provider to trigger a temporary denial of service on platforms where a one-byte over-read can crash the process. It affects both the server and libpq.

• Affected: All versions before 17.5, 16.9, 15.13, 14.18, and 13.21
• Fixed in: 17.5, 16.9, 15.13, 14.18, 13.21

The takeaway for anyone on PostgreSQL 14: every one of these CVEs already required a 14.x minor upgrade to remediate. That mechanism disappears on November 12, 2026. After EOL, a flaw in this same pattern leaves version 14 exposed with no community fix path.

‍

What Happens After End of Life

When a PostgreSQL major version reaches EOL, three things happen:

1. Security patches stop. New CVEs disclosed against the engine, libpq, and the client utilities go unpatched for that branch. Given the recent cadence of SQL-injection and code-injection CVEs that hit every branch at once, this is a concrete and recurring exposure, not a theoretical one.
   
   
2. Platform and ecosystem compatibility degrades. Managed providers stop offering EOL engine versions for new instances and begin enforced upgrades or extended-support surcharges. Amazon RDS, Google Cloud SQL, and Azure Database for PostgreSQL all bill for or force migration off community-EOL versions. Newer extensions, client drivers, and OS packages also stop testing against EOL server versions, so upgrades elsewhere in your stack gradually break compatibility.
   
   
3. Compliance audits flag it. SOC 2, PCI DSS, HIPAA, FedRAMP, and the EU Cyber Resilience Act all require maintained, patched software. An EOL database engine is exactly the kind of finding scanners surface as "EOL/Obsolete Software Detected," and it is increasingly hard to wave past an auditor.
   
   

The complicating factor unique to databases is that the upgrade is stateful. Unlike a stateless application dependency, moving PostgreSQL major versions means migrating live production data via pg_upgrade or logical replication, validating extension compatibility (a frequent blocker, since extensions like PostGIS, TimescaleDB, or pg_partman must support both source and target), checking for planner and behavior regressions, and scheduling a cutover window. That is why so many instances sit on EOL versions: the upgrade is real work on a system you cannot afford to corrupt.

‍

Options for EOL PostgreSQL Versions

If you are running PostgreSQL 14 (approaching EOL), 13, or 12, you have three realistic paths.

1. Upgrade to a supported major version. The right long-term move for most teams. Use pg_upgrade for an in-place jump or logical replication for a lower-downtime cutover, and budget for extension compatibility testing and planner regression validation. The cost is the engineering time, the maintenance window, and the risk inherent in migrating a stateful system, which is why this is rarely a same-quarter decision.

2. Pay for managed extended support. If you run on RDS, Cloud SQL, or Azure, the provider will keep an EOL version patched for a fee. This buys time but is metered, often escalating, and ties you to that provider's patch scope and timeline rather than your own.

3. Adopt commercial Never-Ending Support. HeroDevs Never-Ending Support (NES) for PostgreSQL is a secure, drop-in replacement for EOL PostgreSQL that ships security patches the day community support ends, with no gap in coverage. NES currently covers PostgreSQL 12.x, 13.x, and 14.x, with no data migration and no engine swap: you install the drop-in replacement and keep running the version you already depend on. It is backed by an enterprise SLA that stands up to SOC 2, FedRAMP, PCI DSS, and HIPAA, with same-day response for security and data-corruption issues. This is the option for teams that need to stay compliant and patched without forcing a major-version migration onto a tight timeline.

Quick Reference: Is My PostgreSQL Version Supported?

‍

Frequently Asked Questions

When does PostgreSQL 14 reach end of life?

PostgreSQL 14 reaches end of life on November 12, 2026, five years after its September 30, 2021 release. After that date the PostgreSQL community ships its final 14.x minor release and stops providing security patches, bug fixes, and updates for version 14.

Is PostgreSQL 13 still supported?

No. PostgreSQL 13 reached end of life on November 13, 2025. Its final community minor release was 13.23. Any vulnerability disclosed against version 13 after that date will not be patched by the PostgreSQL community.

How long is each PostgreSQL version supported?

Each PostgreSQL major version is supported for five years from its initial release date. During that window it receives minor releases with bug fixes and security patches at least once every three months. There is no extended LTS tier from the community.

What are the risks of running an EOL PostgreSQL version?

Running an EOL version means no security patches for newly disclosed CVEs, degrading compatibility with managed providers and the wider ecosystem, and compliance findings against frameworks like SOC 2, PCI DSS, HIPAA, FedRAMP, and the EU Cyber Resilience Act. Recent PostgreSQL CVEs (including the CVSS 8.1 psql SQL injection in CVE-2025-1094) affected every supported branch at once, so an EOL branch is left exposed the next time a flaw in that pattern appears.

Can I get security patches for PostgreSQL 12, 13, or 14 after EOL?

Yes. HeroDevs Never-Ending Support (NES) for PostgreSQL provides ongoing security patches for PostgreSQL 12.x, 13.x, and 14.x as a drop-in replacement, beginning the day community support ends, with no migration required and an enterprise SLA aligned to SOC 2, FedRAMP, PCI DSS, and HIPAA.

‍

What to Do Now

PostgreSQL's five-year clock is the easiest software lifecycle in your stack to predict and one of the hardest to act on, because the upgrade touches live production data. Version 12 and 13 are already EOL, and version 14 follows on November 12, 2026. CVEs are being disclosed against every active branch, managed providers are tightening their extended-support terms, and compliance frameworks are explicitly flagging unsupported software.

Whether you upgrade, pay your cloud provider for extended support, or adopt NES, the one option that carries real risk is staying on an EOL version with no patch path. If you are running PostgreSQL 12, 13, or 14 and need to stay secure and compliant without an emergency migration, explore NES for PostgreSQL or contact HeroDevs to talk through your options.