PostgreSQL End-of-Life Dates —
Official EOL Schedule for Every Version

PostgreSQL 14 reaches end of life on November 12, 2026 — under six months away. If you are running PostgreSQL 14 in production, that is your most immediate action item. And PostgreSQL 13 is already past EOL — it stopped receiving fixes on November 13, 2025. The good news with PostgreSQL is that none of this is a surprise: its support policy is one of the most predictable in all of software.

Every PostgreSQL major version is supported for exactly five years, a new major ships every year, and end of life always lands in mid-November. That predictability is a gift for planning — but it also means a version goes EOL every single November, and right now PostgreSQL 14 is next in line.

This page is the single reference for PostgreSQL end-of-life dates across every version — with EOL Risk Scores™, the five-year policy explained, and a plain-English upgrade guide.

Complete PostgreSQL EOL Schedule

The versions below are the ones in active use today. PostgreSQL 15 through 18 are supported; 13 and 14 are the urgent ones (13 is already EOL, 14 follows this November); 12 and earlier are long past end of life and should not be running anywhere.

How PostgreSQL Versioning Works — The 5-Year Policy

PostgreSQL's support model is refreshingly simple, and understanding it removes almost all the guesswork from EOL planning.

Each major version is supported for five years. Since PostgreSQL 10, the major version is a single number (10, 11, 12 … 18). A new major release ships roughly every September or October, and each one receives bug fixes and security updates for five years from its release. End of life always falls in mid-November of the fifth year.

Minor releases are not new versions — they are patches. PostgreSQL 16.14 is not a different version from 16.2; it is PostgreSQL 16 with the latest cumulative fixes. Minor releases ship quarterly and you should always run the latest minor for your major. Upgrading a minor (16.13 to 16.14) is a simple binary swap with no data migration. Upgrading a major (14 to 17) is a real migration project — that distinction is the whole game.

PostgreSQL 14 — EOL November 12, 2026

PostgreSQL 13 — Already Past EOL

PostgreSQL 17 & 18 — Current Upgrade Targets

PostgreSQL vs MySQL — EOL Implications

PostgreSQL and MySQL are the two most common open-source relational databases, and many teams run both. Their EOL models, however, are completely different — and confusing one for the other leads to missed deadlines. See the full MySQL EOL guide for that side.

PostgreSQL is predictable; MySQL is not. PostgreSQL gives every major version a clean five-year window with a November EOL. MySQL splits releases into long-lived LTS versions (like 8.4) and short-lived quarterly Innovation releases (the 9.x series) that EOL within months — so a "newer" MySQL version can be far less supported than an older one. With PostgreSQL, the higher number is always the safer bet; with MySQL, that is not true.

They are not interchangeable at EOL. A PostgreSQL 14 EOL date tells you nothing about your MySQL or MariaDB versions, and vice versa. Track each engine's dates separately. If you run a mixed estate, the Stack Scanner will surface every database version's status at once rather than making you check three policies by hand.

Managed PostgreSQL follows the community dates — and enforces them. Amazon RDS and Aurora PostgreSQL, Azure Database for PostgreSQL, and Google Cloud SQL all track the community EOL schedule, and most will force an automatic major-version upgrade after the community EOL date if you have not upgraded yourself. That is convenient until it happens during business hours unannounced — confirm your provider's forced-upgrade policy with the EOL Checker and upgrade on your own terms first.

How to Upgrade Safely

• 01
  Confirm your current major and minor version Run SELECT version();. The major number (13, 14, 15 …) determines your EOL date — cross-reference it against the table above. Also confirm you are on the latest minor for your major; if not, apply the minor update first, as it is a simple binary swap with no migration.
• 02
  Choose your target major version For most teams: PostgreSQL 17 for the best balance of maturity and runway, or 18 for maximum runway. You can upgrade directly across multiple major versions (13 → 17 in one step), so there is no need to hop through each intermediate release.
• 03
  Pick an upgrade method pg_upgrade is the standard in-place path and is fast even on large databases (use --link mode to avoid copying data files). For near-zero downtime, use logical replication to stand up the new version alongside the old and cut over. pg_dump / pg_restore is the simplest but slowest, best for smaller databases.
• 04
  Check extension compatibility first Extensions are the most common upgrade blocker. Confirm that PostGIS, pg_stat_statements, pgvector, and any others you depend on have releases supporting your target version — and that the target's package repository ships them. An incompatible extension can hard-block pg_upgrade.
• 05
  Test on a clone and watch for deprecations Restore a copy at the new version and run your full application test suite. Watch for removed configuration parameters, changed defaults, collation/locale changes (a frequent source of index corruption across upgrades), and any reliance on deprecated functions. Resolve every issue in the clone before touching production.
• 06
  Back up before every step and re-ANALYZE after Take a verified backup (pg_dump or a base backup) before you begin and confirm it restores. After pg_upgrade, run ANALYZE across the cluster to rebuild planner statistics — skipping this is a classic cause of post-upgrade performance regressions that get blamed on the new version.