PostgreSQL 14 Upgrade Planning Before November 2026 End of Life — when and how should I migrate?
Choose an upgrade path from PostgreSQL 14 while the support window is still open, avoiding a rushed migration close to the November 12, 2026 end-of-life date.
Blockers
- package/postgresql-15 — EOL 2027-11-11
- PostgreSQL 17 changed maintenance-function search_path behavior and removed old_snapshot_threshold, db_user_namespace, and adminpack.
- PostgreSQL 16 changed PL/pgSQL bound cursor assignment behavior, REINDEX DATABASE behavior for system catalogs, and tightened GENERATED-expression rules.
- PostgreSQL 15 changed defaults around CREATE permission and ownership on the public schema and removed exclusive backup mode, older backup function names, plpython2u, and plpythonu.
Who this is for
- low-ops
- enterprise
- small-team
Candidates
Upgrade directly from PostgreSQL 14 to PostgreSQL 17
As of 2026-04-05, PostgreSQL 17.9 is supported and PostgreSQL 14.22 remains supported only until November 12, 2026, while PostgreSQL 17 is scheduled for support through November 8, 2029. PostgreSQL's versioning policy explicitly allows upgrading across major versions without stepping through intervening releases, though it recommends reading all intervening release notes. PostgreSQL 17 adds notable improvements such as better VACUUM memory behavior, SQL/JSON JSON_TABLE(), performance work for sequential reads and write throughput, incremental pg_basebackup, and pg_upgrade preservation of logical replication slots and subscription state for future upgrades. This is the longest-lived target available from the versions already well-established by 2026-04-05.
When to choose
Use this when you want the longest remaining support window and do not want to repeat another major upgrade soon after leaving PostgreSQL 14. It is the strongest default if your extensions, drivers, and managed platform already support PostgreSQL 17.
Tradeoffs
Best support runway and newer replication and backup capabilities, but it has the largest compatibility review surface because you must account for PostgreSQL 15, 16, and 17 release-note changes.
Cautions
PostgreSQL 17 changed maintenance-function search_path behavior, removed old_snapshot_threshold, db_user_namespace, and adminpack, and renamed or removed several monitoring fields. If your upgrade process depends on standbys, pg_upgrade documentation says standby handling still needs explicit planning, and if the old primary is prior to 17.0 some slot recreation steps still apply.
Upgrade directly from PostgreSQL 14 to PostgreSQL 16
As of 2026-04-05, PostgreSQL 16.13 is supported through November 9, 2028, giving roughly two extra years beyond PostgreSQL 14's November 12, 2026 end of life. PostgreSQL's versioning policy allows a direct 14-to-16 major upgrade without an intermediate stop. PostgreSQL 16 added logical replication from standby servers, parallel apply for large logical replication transactions, the new pg_stat_io view, and SQL/JSON constructors and identity functions. This is the more conservative long-lived landing zone if you want substantial runway without taking the newest generally available branch.
When to choose
Use this when you want a safer standardization target than PostgreSQL 17 but still want to avoid landing on a version that expires soon. It is the pragmatic choice when extension or managed-service support for PostgreSQL 17 is not yet fully clear.
Tradeoffs
Long support runway with fewer fresh changes than PostgreSQL 17, but you give up about one year of remaining support and some newer replication and backup improvements.
Cautions
PostgreSQL 16 changed PL/pgSQL bound cursor assignment behavior, disallowed NULLS NOT DISTINCT indexes for primary keys, changed REINDEX DATABASE behavior for system catalogs, and tightened GENERATED-expression rules on inherited and partitioned tables. You still need a dump/restore, pg_upgrade, or logical replication strategy for the major upgrade itself.
Upgrade from PostgreSQL 14 to PostgreSQL 15 only as a compatibility bridge
As of 2026-04-05, PostgreSQL 15.17 is supported only until November 11, 2027, so it buys about one extra year beyond PostgreSQL 14 but not a long planning horizon. PostgreSQL 15 introduced SQL MERGE, selective logical replication with column lists and row filters, zstd compression support, and JSON log output. It can be a deliberate short-hop if a critical extension, vendor image, or internal compatibility policy blocks PostgreSQL 16 or 17 right now. It should not be the default destination if the goal is to avoid another major upgrade soon.
When to choose
Use this only when a blocker prevents immediate adoption of PostgreSQL 16 or 17 and you need a short stabilization step while PostgreSQL 14 is still supported. It is a bridge option, not an endpoint for teams trying to reduce upgrade churn.
Tradeoffs
Lowest feature-jump from PostgreSQL 14 among supported targets, but it leaves a much shorter support runway and likely forces another major upgrade in the near term.
Cautions
PostgreSQL 15 changed defaults around CREATE permission and ownership on the public schema for new clusters and new databases, removed exclusive backup mode and older backup function names, removed plpython2u and plpythonu, and can expose dump/restore issues if empty lexemes exist in tsvector-related data paths. Treat it as a temporary compatibility waypoint, not a long-term answer.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "PostgreSQL 14 Upgrade Planning Before November 2026 End of Life — when and how should I migrate?"