PostgreSQL 15 vs 16 vs 17 Standardization Ahead of PostgreSQL 14 EOL — when and how should I migrate?
Choose the new database baseline for net-new services and managed clusters as PostgreSQL 14 approaches end of support.
Blockers
- package/postgresql-15 — EOL 2027-11-11
Who this is for
- low-ops
- enterprise
- cost-sensitive
Candidates
Standardize on PostgreSQL 16
PostgreSQL 16 is the middle-ground baseline: current minor 16.13 and community support through November 9, 2028, as of 2026-04-04. PostgreSQL itself remains free software under the PostgreSQL License, so there is no version-specific license fee for 15, 16, or 17; for managed cluster pricing, check official provider docs. Version 16 adds 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. Its migration notes are meaningful but narrower than jumping straight to 17.
When to choose
Use this for low-ops and enterprise fleets that want more runway than 15 without taking the newest major as the default. It is the safer standardization point when extension support, provider rollout timing, or internal certification tends to lag the latest release by one major.
Tradeoffs
Longer support horizon than 15 and fewer adoption-risk questions than 17, but it gives up 17-specific upgrade and backup improvements. You will likely revisit the baseline sooner than if you standardize directly on 17.
Cautions
Major upgrades still require `pg_upgrade`, dump/restore, or logical replication. Verified migration caveats include stricter `CREATEROLE` behavior, changed role inheritance defaults at `GRANT` time, removal of `promote_trigger_file`, `vacuum_defer_cleanup_age`, and manual view creation with `ON SELECT` rules, plus tighter generated-column restrictions on inherited and partitioned tables.
Standardize on PostgreSQL 17
PostgreSQL 17 is the longest-lived candidate here: current minor 17.9 and community support through November 8, 2029, as of 2026-04-04. PostgreSQL itself has no license fee under the PostgreSQL License, so the version decision is about support runway and migration behavior rather than database software cost. Version 17 adds incremental backup support in `pg_basebackup`, failover-oriented logical replication improvements, `pg_createsubscriber`, and `pg_upgrade` preservation of logical replication slots and subscription state for future major upgrades. For net-new services, it offers the best lifecycle runway before the next standardization cycle.
When to choose
Use this when you want the default for new services to maximize support horizon and reduce future re-baselining churn. It is the strongest choice if your managed provider and required extensions already support 17 cleanly and you value future major-upgrade ergonomics.
Tradeoffs
Best runway and strongest forward-looking replication and backup story, but it is the newest of the compared majors and may lag slightly in provider maturity or extension certification. Some teams will accept that trade for a later EOL date.
Cautions
Major upgrades still require `pg_upgrade`, dump/restore, or logical replication. Verified migration caveats include safe `search_path` behavior during maintenance operations that can affect expression indexes and materialized views, removal of `adminpack`, `db_user_namespace`, `old_snapshot_threshold`, and some renamed statistics columns that can break monitoring or maintenance scripts.
Standardize on PostgreSQL 15 only as a short-lived compatibility hold
PostgreSQL 15 remains supported with current minor 15.17 through November 11, 2027, as of 2026-04-04. It has no PostgreSQL software license fee, just like 16 and 17, so choosing it does not save on community database licensing. PostgreSQL 15 introduced `MERGE`, logical replication row filters and column lists, zstd compression support, and JSON server log output. The main issue is not capability but runway: it only extends community support by about one year beyond PostgreSQL 14.
When to choose
Use this only if a blocker such as provider support, extension compatibility, or internal certification prevents 16 or 17 today. It fits a constrained transition plan where you need to get off 14 quickly but already know another major upgrade will follow soon.
Tradeoffs
Lowest change risk if your tooling has already validated 15, but it creates a shorter-lived baseline and more near-term upgrade pressure. For net-new services, it usually defers rather than solves the standardization problem.
Cautions
Verified migration caveats include the new default that removes `CREATE` permission for `PUBLIC` on the `public` schema in new clusters and databases, ownership of `public` moving to `pg_database_owner`, removal of exclusive backup mode and related function renames, removal of `plpython2u` and `plpythonu`, and `libpq` pipeline-mode changes around `PQsendQuery()`. These are manageable, but the bigger caution is the short support window.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "PostgreSQL 15 vs 16 vs 17 Standardization Ahead of PostgreSQL 14 EOL — when and how should I migrate?"