PostgreSQL 14 reached end of life today. The community shipped version 14.25 — the final minor release — patched 52 security vulnerabilities, and closed the books. No more fixes. Ever. If a new CVE hits PostgreSQL 14 next week, it goes unpatched permanently. If you’re running PG14 in production, the window to act without real urgency just closed.
The CVE count is not a footnote
PostgreSQL 14 accumulated 44 CVEs in 2026 alone. Twenty-two of them scored 8.0 or higher on the CVSS scale. The final 14.25 release just patched a batch that included three entries at CVSS 8.8 — one step below the top of the scale. CVE-2026-120145 lets logical replication write to subscriber system catalogs and execute arbitrary code. CVE-2026-120149 triggers the same outcome through a FDW batch-insert type mismatch. CVE-2026-116328 is a memory context integer wraparound with the same severity rating.
These are now fixed. But any new vulnerability discovered after today joins this list permanently, with no patch ever coming. A PostgreSQL 14 instance frozen at 14.25 will accumulate documented, exploitable, unpatched CVEs for as long as it runs. That is what end of life means in practice.
Where to go: PostgreSQL 18
The target is PostgreSQL 18, which shipped version 18.7 today alongside the final PG14 release. It is supported until November 2030 — four years of runway. PostgreSQL 19 RC2 also dropped today, but release candidates are not production-ready. Go to 18.
The practical upside: pg_upgrade supports direct migration from 14 to 18. You do not need to hop through 15, 16, and 17 as intermediate steps. Skip straight to the current stable release.
Three upgrade paths
| Method | Downtime | Complexity | Best For |
|---|---|---|---|
| pg_upgrade | Minutes to hours | Medium | Most self-managed installs |
| Dump and restore | Hours | Low | Small databases, clean start |
| Logical replication | Seconds | High | Zero-downtime requirement |
pg_upgrade is the right call for most self-managed PostgreSQL deployments. Install PG18 alongside PG14, run a dry-run check, stop the old server, run the upgrade, then run vacuumdb analysis. The check mode is non-destructive and can run while the old server is still live:
pg_upgrade --check \
-d /var/lib/postgresql/14/main \
-D /var/lib/postgresql/18/main \
-b /usr/lib/postgresql/14/bin \
-B /usr/lib/postgresql/18/binLogical replication gets you near-zero downtime but carries a meaningful caveat from PG14: pg_upgrade only carries logical replication slots and subscriptions from PostgreSQL 17 and later. From 14, you must recreate them manually after cutover. Enable wal_level = logical on PG14 first (requires a server restart), create a PUBLICATION on 14, create a SUBSCRIPTION on 18, wait for sync, then cut over. Sequence values and large objects do not replicate — handle those separately.
Four gotchas that will stall your upgrade
1. Data checksum mismatch. PostgreSQL 18 enables data checksums by default when initdb creates a new cluster. If your PG14 cluster was initialized years ago without checksums, pg_upgrade will refuse to run. Fix: use initdb --no-data-checksums when setting up the new 18 cluster, or enable checksums on PG14 before you start.
2. Extension compatibility. Every extension needs a PG18 build installed before pg_upgrade runs. Check pgvector, TimescaleDB, PostGIS, and any other extensions you use. On Azure, non-core extensions are not upgraded automatically — they need manual ALTER EXTENSION ... UPDATE or recreation after the upgrade. Confirm PG18 builds exist on your platform before you start the maintenance window.
3. MD5 password deprecation. PostgreSQL 18 deprecates MD5 authentication in favor of SCRAM-SHA-256. Audit your roles and migrate them before upgrading. pg_upgrade will not block on this, but authentication failures after cutover are unpleasant.
4. Removed settings and extensions. vacuum_defer_cleanup_age, promote_trigger_file, old_snapshot_threshold, and the adminpack extension were removed in PG18. Your postgresql.conf will need cleanup. Read the release notes for every major version you are crossing.
AWS and Aurora users: more time, but it costs
Amazon RDS and Aurora PostgreSQL 14 stay in standard support until February 28, 2027. Extended Support kicks in March 1, 2027 — AWS keeps shipping security fixes, but you pay extra per instance-hour on top of normal pricing. That rate increases again in 2029. The pragmatic answer is to upgrade before the February deadline and skip the tax entirely.
Check your version now:
SELECT version();If that returns anything starting with PostgreSQL 14, you have work to do. The official pg_upgrade documentation is thorough and worth reading before you start a maintenance window. The full CVE list and detailed upgrade notes are in the release announcement.
