Runtime
PostgreSQL Global Development Group
PostgreSQL 14 reaches end of life — after 12 November 2026 the community ships no further bug fixes or security patches for the 14.x line
departs 12 Nov 2026
Quick answers
- Is it true that PostgreSQL 14 reaches end of life on 12 November 2026?
- Yes. PostgreSQL Global Development Group has officially announced it, effective 12 Nov 2026. The PostgreSQL project supports each major version for five years, and its official versioning policy lists PostgreSQL 14 (current minor 14.24) with a final release date of 12 November 2026.
- When does it take effect?
- 12 Nov 2026. Verified against the vendor's own announcement.
- What should I use instead?
- Upgrade to a supported major version before 12 November 2026 — PostgreSQL 15 (EOL 11 November 2027), 16 (9 November 2028), 17 (8 November 2029), or 18 (14 November 2030).
What this means for you
The PostgreSQL project supports each major version for five years, and its official versioning policy lists PostgreSQL 14 (current minor 14.24) with a final release date of 12 November 2026. After that date the community releases no further minor versions for 14.x — no bug fixes and, critically, no security patches. A PostgreSQL 14 server keeps running, but any vulnerability found in the server after that date goes unfixed on 14, so anything internet-reachable or holding regulated data becomes a compliance and security problem the day a relevant CVE lands. This affects a very large installed base: self-managed clusters pinned to 14, containers built `FROM postgres:14`, and CI/test databases that quietly pin the major. Managed providers set their own timelines that usually track the community EOL — AWS RDS, Azure Database for PostgreSQL, Google Cloud SQL and others typically force an upgrade or move you to paid extended support around the same window, so the community date is the one to plan against.
Where to go
Upgrade to a supported major version before 12 November 2026 — PostgreSQL 15 (EOL 11 November 2027), 16 (9 November 2028), 17 (8 November 2029), or 18 (14 November 2030). Moving to 17 or 18 buys the longest runway. Plan a major-version upgrade using `pg_upgrade` (fast, in-place) or logical replication / dump-and-restore for a low-downtime cutover, and test on a copy first — major upgrades can require reindexing and application checks for changed defaults. In Dockerfiles and compose files, bump `postgres:14` base images to a supported tag. If you run managed PostgreSQL, check your provider's specific PostgreSQL 14 retirement date and their extended-support pricing, since forced upgrades and billing changes are usually scheduled around the community EOL.
- PostgreSQL 17 — supported through 8 November 2029
- PostgreSQL 18 — supported through 14 November 2030 (longest runway)
- PostgreSQL 15 or 16 — nearer upgrade targets if a smaller version jump is preferred
The PostgreSQL project’s official versioning policy gives every major version five years of support, and its supported-versions table lists PostgreSQL 14 (current minor 14.24) with a final release date of 12 November 2026. That is the end of the line for the 14.x series.
End of life means one thing that matters: after 12 November 2026, the community ships no further minor releases for PostgreSQL 14 — no bug fixes and no security patches. Your database does not stop working that day. What changes is that the next security vulnerability found in the server never gets fixed on 14. You either carry that risk or upgrade.
The exposure is largest where the database is reachable or holds sensitive data: internet-facing services on a 14 cluster, workloads under a compliance regime, and containers built FROM postgres:14 that other images inherit without anyone noticing the version underneath. Self-managed clusters are the clearest case, but managed PostgreSQL is affected too — AWS RDS, Azure Database for PostgreSQL, and Google Cloud SQL each set their own PostgreSQL 14 retirement dates that generally track the community EOL, usually with a forced upgrade or a move to paid extended support around the same window. The community date is the one to plan the migration against.
The upgrade target is any still-supported major: PostgreSQL 15 (EOL 11 November 2027), 16 (9 November 2028), 17 (8 November 2029), or 18 (14 November 2030). Jumping straight to 17 or 18 buys the longest runway before the next end-of-life date. Use pg_upgrade for a fast in-place upgrade, or logical replication / dump-and-restore for a lower-downtime cutover, and rehearse on a copy first — major-version upgrades can need reindexing and a check for changed defaults. In Dockerfiles and compose files, bump postgres:14 to a supported tag. If you can’t move everything in time, at minimum inventory which clusters still run 14 so you know exactly what becomes unpatchable in November.
Entry changelog
- — last reviewed.
- — Entry created from the PostgreSQL project's official versioning policy table, which lists version 14 (current minor 14.24) with a final release / end-of-life date of 12 November 2026 and version 18 supported through 14 November 2030 — all read directly from the supported-versions table. detect: fingerprint targets the going-away `postgres:14` container image tag only, never a supported successor; CLI-validated against a scratch repo before publishing.
Put this countdown in your README
Building on PostgreSQL Global Development Group? Drop this badge into a project’s README or docs — it shows the days left and
refreshes on its own every night from this page. 
[](https://lastcall.dev/entries/postgresql-14-end-of-life)Spot an error or a changed date? Tell us and it’s corrected the same night.