Postgres EOL: PostgreSQL End of Life Dates by Version

PostgreSQL 14 reaches end of life on 12 November 2026, PostgreSQL 13 reached it on 13 November 2025 and PostgreSQL 12 on 21 November 2024. Versions 15, 16, 17 and 18 are supported until November 2027, 2028, 2029 and 2030. Each major version gets five years of community fixes, then a final minor release, and the last few have all landed in November. The dates below come from the PostgreSQL versioning policy page, checked on 9 October 2026, together with the AWS, Azure and Google Cloud lifecycle pages for managed Postgres.

PostgreSQL versioning policy in one paragraph

The PostgreSQL Global Development Group ships a new major version about once a year and supports each one for 5 years after its initial release. During that window every major version receives bug fixes and security fixes in a minor release at least once every three months. After five years a final minor version is released and that version is unsupported: end of life (EOL). Since PostgreSQL 10 the major version is the first number, so 14 to 15 is a major upgrade and 14.23 to 14.24 is a minor one. Minor upgrades only swap binaries and restart. Major upgrades change the data directory format and need pg_upgrade, a dump and restore, or replication.

PostgreSQL EOL dates by version

Source: PostgreSQL versioning policy. Two readings matter for planning. PostgreSQL 14 has one more minor release left, so a Postgres 14 estate has weeks, not quarters, before new CVEs stop being fixed. And PostgreSQL 15 follows twelve months later, on 11 November 2027, so a team that upgrades 14 only to 15 will be doing this again next year. Most teams should target 17 or 18.

What PostgreSQL end of life means in practice

Nothing stops working on the EOL date. The server keeps running and accepting connections, which is why EOL clusters linger in production. What ends is the supply of fixes. The PostgreSQL security page says plainly that no further security patches are made available for versions that are end of life. A vulnerability disclosed next year will be patched in 15 through 18 and left open in 14. Bug fixes for data corruption and crash issues stop at the same moment. Auditors treat an unsupported database as a finding, and every PostgreSQL version upgrade you postpone gets wider.

RDS, Aurora, Azure and Cloud SQL: what happens to managed Postgres past EOL

All three large clouds now follow the same pattern for an EOL Postgres version: a short period of standard support after the community date, then automatic, paid extended support for up to three years, then a forced major version upgrade.

• Amazon RDS for PostgreSQL and Aurora PostgreSQL. RDS keeps standard support until 28 February 2027 for PostgreSQL 14 and ended it on 28 February 2026 for 13. The day after, instances are enrolled in RDS Extended Support and charged per vCPU per hour, with a different rate from year three. Extended Support for 14 runs to 28 February 2030 and for 13 to 28 February 2029. RDS Extended Support covers critical and high CVEs and critical bug fixes. When it ends, or if you disable enrollment on a database that is already past its standard support date, AWS upgrades the instance to the next supported major version automatically.
• Azure Database for PostgreSQL flexible server. Standard support for 11, 12 and 13 ended on 31 July 2026. Those servers were enrolled automatically in extended support on 1 August 2026 and billed from 1 September 2026. Microsoft's FAQ says you cannot opt out except by upgrading. Extended support ends on 31 March 2027 for 11, 13 November 2027 for 12, 12 November 2028 for 13 and 11 November 2029 for 14.
• Google Cloud SQL for PostgreSQL. A version enters paid extended support at the Cloud SQL end-of-life date, normally three months after the community date: 1 February 2026 for 13 and 1 February 2027 for 14. Extended support lasts three years. After that the version is deprecated and Cloud SQL upgrades instances to the default major version during maintenance. Versions 9.6 through 12 entered extended support with billing from 1 May 2025 and are deprecated on 1 February 2028.

The practical consequence: on RDS, Aurora, Azure and Cloud SQL, an EOL Postgres is not free to keep, and the upgrade happens on the provider's calendar if it does not happen on yours. RDS Extended Support charges also apply to standby instances in Multi-AZ deployments, so check the bill per cluster, not per primary.

Your options for a PostgreSQL version past end of life

• Keep the version and keep it patched. OSSeva, AceMQ's extended support platform, backports CVE fixes to PostgreSQL 11, 12 and 13 after community end of life, and to 14 once its community support ends on 12 November 2026. Patched builds ship as signed RPM and DEB packages and tarballs, install like a minor release on the same data directory, and are validated for third-party extension compatibility. This removes the security argument for an upgrade you cannot run this quarter.
• Put an operations team behind it. Patches close the vulnerability gap; they do not answer the phone at 3am. AceMQ provides 24/7 PostgreSQL support for self-managed and cloud-hosted Postgres on any version, and plans and runs the upgrade with you. For how support works more broadly, see PostgreSQL support options.
• Pay the cloud provider's extended support. Reasonable as a short bridge. It is billed on top of the instance and ends in a forced upgrade.
• Upgrade to a supported major. The right end state. For most estates that means PostgreSQL 17 or 18.

How to upgrade off an end-of-life PostgreSQL version

Start with an inventory. Run SELECT version(); and SELECT extname, extversion FROM pg_extension; on every cluster. You can upgrade from one major version to any later one without stopping at the versions in between, but the community recommends reading the release notes of every intervening major first.

pg_upgrade migrates a cluster in place and, particularly in --link mode, can finish in minutes. It needs a maintenance window, matching extension shared object files installed for the new version, and a rollback plan, because in link mode you cannot access the old cluster once the new one has started. Clone mode, or upgrading a copy, keeps the old cluster intact. When the target is PostgreSQL 18, pg_upgrade transfers most optimizer statistics, but not extended statistics created with CREATE STATISTICS, so run vacuumdb --all --analyze-in-stages --missing-stats-only afterwards before you trust query plans.

Logical replication works between different major versions, so you can build a new 17 or 18 cluster, replicate into it, and switch over in a short cutover window. The cost is preparation: DDL is not replicated, sequence values must be copied before cutover, and large objects are not replicated at all. Tables without a primary key need a replica identity set before UPDATE and DELETE will replicate.

Either way, most of the effort is testing. PostGIS, pg_partman, TimescaleDB and similar extensions have their own version matrix, query plans can change between majors, and an upgrade from 11, 12 or 13 crosses the PostgreSQL 14 change of the default password_encryption from md5 to scram-sha-256, so check that every client driver supports SCRAM. Rehearse on a copy of production and keep the old version patched until the cutover is done.

• PostgreSQL: Versioning policy and release dates
• PostgreSQL: Security information
• PostgreSQL documentation: Upgrading a PostgreSQL cluster
• PostgreSQL documentation: pg_upgrade
• PostgreSQL documentation: Logical replication restrictions
• PostgreSQL 14 release notes
• AWS: Release calendars for Amazon RDS for PostgreSQL
• AWS: Aurora PostgreSQL release calendar
• AWS: Amazon RDS Extended Support
• AWS: Amazon RDS Extended Support charges
• Microsoft Learn: Azure Database for PostgreSQL extended support
• Google Cloud: Extended support for Cloud SQL for PostgreSQL
• Google Cloud: Database versions and version policies
• OSSeva: PostgreSQL extended support