PostgreSQL 19 was set for its usual fall release, but the project has pushed the date back by weeks to months after committers pulled 53 features since last June's beta — including SQL/PGQ property graph queries and long-requested partition merge/split support. The pattern behind the reversions, more than the delay itself, is the part worth reading closely.
What changed
Beta 4, originally scheduled for September 24, 2026, has slipped along with the rest of the fall timeline; the project now expects the final release "weeks and maybe even months" later than planned.
The reverted feature list runs to 53 items pulled since the June 2025 beta, but two categories stand out. The first is functionality cut for design reasons: SQL/PGQ property graph query support went back over broader design and readiness concerns, and ALTER TABLE MERGE/SPLIT PARTITION(S) — a partition-management feature requested for years — was pulled after committers judged its design problems too late to fix within this cycle. UPDATE/DELETE FOR PORTION OF, aimed at temporal range columns, was reverted for similar reasons.
The second category is more concerning for anyone tracking PostgreSQL's release discipline: correctness bugs caught after the code had already been committed. GROUP BY ALL is the clearest example — post-commit review found it "missed special handling of ORDER BY entries with nondefault equality semantics, producing wrong results," meaning queries using the feature could silently return incorrect data rather than merely fail to compile. A default of lz4 for TOAST compression was also reverted, in this case for missing buildfarm test coverage that would need to be rebuilt from scratch.
The rest of the list is long: non-text output formats for pg_dumpall, cascading ON ERROR handling in JSON_TABLE, fast domain defaults, logical replication snapshots, nested query tracking, and online data checksums all got pulled as well. Coverage of the delay notes that AI-assisted bug-finding tools played a role in surfacing some of these problems — after the code was already merged, not before. PostgreSQL's release process runs through roughly 30 committers working the open commitfest queue and the pgsql-hackers mailing list; no individual committer is named for any specific reversion.
Who this affects
Teams that had scoped a project around SQL/PGQ's graph queries or the new partition MERGE/SPLIT syntax should assume neither lands in PostgreSQL 19 and plan around PostgreSQL 20 instead, since both were cut for unresolved design issues rather than a fixable bug. Anyone testing GROUP BY ALL against pre-release builds should discard those results; the construct produced wrong answers under certain ORDER BY conditions and was pulled entirely, so no version of it ships in 19.
Operators who don't touch any of the specific reverted features see little direct impact — the delay affects the release date, not the stability of features that did survive to the current beta. The likelier practical effect is indirect: a release cycle that let 53 changes reach beta before reversion, several for correctness rather than design reasons, is a data point worth factoring into how early an organization tests against PostgreSQL pre-releases.
Verdict
There's no PostgreSQL 19 to install yet, so the immediate decision isn't upgrade-or-wait — it's what to plan for. Anything built on SQL/PGQ or the new partition merge/split syntax should be re-scoped now, on the assumption that PostgreSQL 20 is the earliest realistic target for either. For everything else, the safer posture is to keep tracking beta builds for correctness issues rather than treating a beta tag as a stability signal, since this cycle demonstrated that features can reach beta with bugs serious enough to produce wrong query results.
Once PostgreSQL 19 actually ships — now expected some weeks to months past its original fall date — the delay itself won't be the story worth remembering. The 53 reversions, and how many of them were correctness bugs rather than missed deadlines, are the more useful signal for judging how carefully to test the next PostgreSQL pre-release before relying on it.
Tracked daily from official release feeds and vendor changelogs. Full archive: https://media.patentllm.org
Top comments (0)