PostgreSQL 19 Sheds Its Headline Features Before Release
Beta 4 reverts property graph queries, online checksums and temporal updates, and the project is right to do it.
The PostgreSQL Global Development Group released PostgreSQL 19 Beta 4 on 24 September, and the changelog reads less like a beta update than a retreat. Among the changes since Beta 3: SQL/PGQ property graph query support is reverted; online enabling and disabling of data checksums is reverted; temporal UPDATE and DELETE using FOR PORTION OF is reverted; ALTER TABLE ... MERGE PARTITIONS and SPLIT PARTITIONS are reverted; and the new pg_get_role_ddl(), pg_get_tablespace_ddl() and pg_get_database_ddl() functions are gone.
Several of those were among the most talked-about additions when the first beta arrived in June. The announcement is direct about why: the community believes PostgreSQL must be reliable first, and wants a predictable release schedule, so features that were not ready have been pulled to be reconsidered for a later major release.
How unusual is this?
PostgreSQL usually ships a new major version in the autumn after a summer of betas, and pulling a feature late is not unheard of. What is unusual in this cycle is the scale. Elizabeth Garrett Christensen at Snowflake, writing a week before Beta 4, listed reverts that also include GROUP BY ALL (post-commit review found wrong results with non-default equality semantics), switching default TOAST compression to lz4, non-text output formats for pg_dumpall, and nested query tracking in pg_stat_statements. Her assessment was that the release would slip by weeks and perhaps months.
Command Prompt's write-up dates two of the biggest reverts: MERGE/SPLIT PARTITION on 27 August, removing 14 commits, and SQL/PGQ on 7 September, removing 47. The partition revert's commit message cited design issues that were too late to address in this cycle.
Why this is the process working
It is tempting to read a list of reverts as a project in trouble. I read it the other way. The alternative is shipping a graph query implementation with known design gaps, or an online checksum switch, which touches the integrity of every page on disk, before it is trusted. Database features are unusually hard to take back once people depend on them, and a wrong-results bug in GROUP BY is the kind of defect that erodes trust in a database for years.
PostgreSQL's commit-then-review model lets features land early so they get real testing, and accepts that some will be removed. That only works if the project is willing to remove them, and this cycle shows that it is.
What is still in 19
Quite a lot. Beta 4's fixes touch features that remain: the new REPACK and WAIT FOR commands, a new autovacuum scoring system, a SIMD optimisation for COPY FROM, faster foreign key checks, CREATE PUBLICATION ... EXCEPT, and logical replication conflict detection. Christensen's list of remaining highlights adds pg_plan_advice for query plan hints, parallel autovacuum, ON CONFLICT DO SELECT, and IGNORE NULLS in window functions. There is also a fix for initial table synchronisation when replicating from an older PostgreSQL version into 19, which is exactly the path many teams will use to upgrade.
On timing, the project says a release candidate should follow in early October and general availability could also come in October, depending on testing.
What this means for planning
- Plan production upgrades around PostgreSQL 18. Both Christensen and Command Prompt make this recommendation, and I agree. Treat 19 as something to test, not something to schedule.
- If you built on a beta feature, remove it now. Anyone who prototyped against SQL/PGQ or
FOR PORTION OFshould not expect them before PostgreSQL 20. - Watch PostgreSQL 14's end of life. Command Prompt notes it is due on 12 November. Teams on 14 should be moving to 17 or 18, not waiting for 19.
- Keep testing the betas. Moving between betas needs
pg_upgradeor a dump and restore, but bug reports from real workloads are what get the release candidate out on time.
Sources