PostgreSQL 19 ships 19 November as PostgreSQL 14 support ends days earlier

A release date and an end date in the same week

PostgreSQL 19 becomes generally available on 19 November 2026, according to the project's release-candidate announcement summarised in a dev.to briefing. A second release candidate, RC 2, arrives a week earlier on 12 November, alongside the quarterly minor-release round for all supported versions.

That same 12 November date marks the end of the line for PostgreSQL 14. The project backs each major version with five years of bug and security fixes from its first release, closing the branch with a final minor version — 14.24 in this case. Version 14 originally shipped on 30 September 2021, so after 12 November a cluster still running it receives no further corrections.

What lands in PostgreSQL 19

The headline feature for day-to-day operations is REPACK, a single command that replaces both VACUUM FULL and CLUSTER. The older commands remain available for compatibility. REPACK (CONCURRENTLY) rebuilds a table without taking an access-exclusive lock, which the briefing flags as the variant most operators will actually use.

Planner behaviour gains two extensions. pg_plan_advice stabilises and steers planner decisions, while pg_stash_advice applies stored advice automatically, keyed to a query. On the maintenance side, autovacuum picks up parallel index processing and a scoring system that decides which tables it should visit first, with I/O worker processes tunable through io_min_workers and io_max_workers.

Replication sees the two changes with the most impact on busy clusters: logical replication can now be switched on by setting wal_level to replica without restarting the server, and sequence values replicate logically. A new WAIT command lets a standby hold until a given log position has been written, flushed or replayed.

Defaults that change under an upgraded cluster

According to the release notes cited by dev.to, five defaults shift once a cluster is restored into 19:

• JIT compilation ships disabled, because the optimizer cost that used to trigger it proved unreliable. Sites running heavy analytical queries must re-enable it deliberately.
• max_locks_per_transaction rises from 64 to 128; the underlying lock-size allocation changed, so related settings must double to preserve previous capacity.
• standard_conforming_strings is now always on in the server, and a dump produced by a pre-19 pg_dump while the setting was off will not load into 19.
• RADIUS authentication is removed; the project considered its UDP-only transport impossible to secure.
• Indexes on inet and cidr types default to GiST rather than the previous opclasses.

The path off version 14

The release notes accept three migration routes: a dump and restore with pg_dumpall, pg_upgrade, or logical replication. Of these, pg_upgrade warrants explicit preflight checks because it refuses to run against certain clusters. Two refusal conditions are worth testing for in advance: btree_gist indexes on inet or cidr columns, and carriage returns or line feeds embedded in database, role or tablespace names. Separately, MULE_INTERNAL encoding is gone, so databases that use it require a dump and restore into a different encoding.

The briefing's practical guidance is to rehearse the chosen route on a production-like copy, run critical queries against it, and confirm backups, the rollback procedure and the maintenance-window duration before approving the real migration. Every documented incompatibility is a fact that can be found beforehand, and any one of them can derail a migration if it first appears mid-run.

Why it matters

Teams still on PostgreSQL 14 face a hard deadline: no fixes of any kind after 12 November, a week before the new release arrives. The upgrade is less risky than that timing suggests, because the blocking conditions — nonstandard encodings, btree_gist opclasses, string-handling defaults — are discoverable with a preflight query rather than a failed maintenance window. The project also publishes its end-of-support dates years ahead; its support table lists version 18 through November 2030. For any organisation, the database version in production is effectively a scheduled obligation with a known due date, not a surprise.