PostgreSQL 19’s release tracker lists November 19, 2026, as the planned general-availability date, following an October 15 release candidate and ahead of a planned November 12 second candidate. For engineers preparing upgrades, the important change is not simply the calendar: several substantial features advertised during development have been removed from the release.
The project’s release tracker labels general availability as planned, not guaranteed. Its schedule differs from the September 24 Beta 4 announcement’s expectation that general availability might occur in October. A release candidate is a testing milestone, not a production-readiness guarantee.
The engineering implication is a narrower upgrade target. Teams must distinguish features removed entirely from features retained after fixes, then test the actual candidate against production-like workloads. A development-era feature list is no longer a sufficient migration specification.
Four removals that change application plans
The official Beta 4 announcement lists four major reversions: SQL/PGQ property-graph queries, online enabling and disabling of data checksums, temporal updates and deletes through FOR PORTION OF, and ALTER TABLE ... MERGE PARTITIONS and SPLIT PARTITIONS.
These are separate application and operational dependencies. A graph-query prototype cannot assume SQL/PGQ will ship in version 19. Temporal-data applications must not schedule a migration around the removed clause. Operations teams should revise runbooks that depended on changing checksum state online or restructuring partitions through the new commands.
The announcement also removes three DDL-inspection functions: pg_get_role_ddl(), pg_get_tablespace_ddl() and pg_get_database_ddl(). Automation written against these development features needs review too. Removed work may return in a later major release after further development and review; the announcement does not promise a specific replacement release.
Why database semantics complicate stabilization
The tracker documents temporal-update problems involving triggers, rules, generated columns and view checks. Several resolved entries point to feature reversion rather than independent fixes that preserve the feature. Multiple reports can expose different manifestations of one architectural interaction; a resolved issue does not necessarily represent a surviving capability.
Property-graph entries similarly include catalog representation, dump support, aggregates and subqueries. For application architects, these are reasons to validate end-to-end lifecycle behavior, including backup and schema tooling, rather than treating successful query execution as complete integration.
Retained features still need regression testing
Not every feature discussed during stabilization was removed. Beta 4 reports fixes to REPACK, WAIT FOR, foreign-key constraint-check optimizations and logical replication. REPACK fixes include crashes, invalid-index and materialized-view behavior, permissions and error reporting. WAIT FOR received a deadlock fix and clearer isolation-level errors.
The tracker adds regression targets involving foreign-key casts and privileges, concurrent-operation and logical-decoding interactions, and logical-replication synchronization from older versions. These entries describe development defects and their recorded disposition, not evidence that the final release retains those defects.
Build the upgrade rehearsal around the candidate
Recommended evaluation priorities are schema compatibility, representative query results, restore behavior, privilege enforcement and replication topology. Include trigger-heavy workloads and extensions where relevant. Keep removed syntax out of migration scripts, and verify retained features against the specific candidate build being evaluated.
For Beta 4 specifically, the project requires an upgrade strategy resembling a major-version migration, such as pg_upgrade or pg_dump/pg_restore. Do not generalize that instruction into a guarantee about every subsequent candidate; consult its release instructions.
PostgreSQL 19’s revised scope favors shipping a smaller, reviewed feature set over preserving every development commitment. November 19 remains a target. The practical decision for CTOs is whether their upgrade plan depends on capabilities confirmed in the candidate—or on promises already removed from it.
