What changed
The PostgreSQL Global Development Group released PostgreSQL 19 RC1 on October 15, 2026. It now plans a second release candidate on November 12 and general availability on November 19, superseding a September 28 plan targeting October 29. The stated reason is to incorporate the large November 12 maintenance-fix batch before GA. RC1 includes fixes since Beta 4 for concurrent REPACK, pg_plan_advice, NULL-sensitive planner optimisations, automatic logical replication, postgres_fdw statistics, parallel autovacuum and JSON COPY column naming.
Why it matters
Database operators planning autumn upgrades need to adjust release calendars and test operational changes against their own extensions and query workloads. The release is not simply a feature preview: maintenance, planner and replication semantics can affect deployment behaviour, locking, query plans and recovery. A release candidate is not a production upgrade recommendation, and the final feature set must be read from current upstream notes rather than older beta summaries.
The schedule has shifted by three weeks
PostgreSQL's September 28 developer-list message targeted October 29 GA. The October 15 RC1 announcement instead schedules RC2 for November 12 and GA for November 19 to fold in the substantial November maintenance patch batch. Both dates remain subject to further issues.
What the release candidate fixes
Upstream lists several fixes to REPACK (CONCURRENTLY), pg_plan_advice, query planning around nullable expressions, automatic logical replication with wal_level=replica, postgres_fdw statistics import permissions, parallel autovacuum and COPY(query) TO JSON column naming. These are concrete compatibility and correctness areas to exercise in test environments.
Why operational features matter
PostgreSQL 19's native concurrent REPACK and parallel autovacuum can alter how operators reclaim space and maintain busy databases. Replication improvements and WAIT/read-your-writes behaviour could simplify some application patterns. Performance and lock behaviour must still be measured under actual workload, not inferred from feature names.
Do not assume every beta feature shipped
The project reverted several planned features during Beta 4. Older previews may mention partition split/merge, temporal modifications or SQL/PGQ graph queries that are not in the current RC. Review the actual PostgreSQL 19 release notes and extension compatibility before updating migration plans.
Upgrade testing and readiness
Moving from an older major PostgreSQL version requires a major-version upgrade strategy such as pg_upgrade or dump/restore. Operators should rehearse upgrades, check extensions, indexes and query plans, validate replication behaviour and await final GA before considering production adoption.