The PostgreSQL Global Development Group has delayed the release of PostgreSQL 19, the newest version of the widely used open source database, and has held back an unusual number of the features it was expected to carry.
The release had been slated for late September or early October. It is now expected to become generally available around 19 November. Between eight and 10 significant features have been dropped and pushed back to PostgreSQL 20, next year's release.
Writing in The Register on Friday, Lindsay Clark reported that the reverts have been attributed, at least in part, to the LLM-assisted code review that PostgreSQL developers have begun using. Peter Eisentraut, a leading PostgreSQL committer and a vice-president at the support and consultancy firm EDB, set out the reasoning in a blog post earlier this month.
Some of the reverted features, he wrote, had significant architectural defects that would have been hard to fix "quickly and during beta".
The automated review also turned up a long tail of what he described as "relatively harmless issues involving various edge cases". In previous release cycles those might have gone unnoticed for years, surfacing as bug reports in the five years after launch.
"With LLM-assisted code review, these kinds of things can get found much faster, and then you're staring at a list of forty defect reports," Eisentraut wrote. "Even if each of them requires only a three-line fix on average, there is a fixed overhead to dealing with each of these, and then you run out of time."
He was careful about what the reverts do not mean. Most of the affected features were written before the technique was available, so the fashionable explanation does not apply. The explanation he offers instead is a procedural one: "The effective quality bar has been raised after the time the feature was written and committed. Unless the capabilities of LLM-assisted code review keep improving at the current rate, this situation should sort itself out for future development cycles."
Among the casualties is support for SQL Property Graph Queries, or SQL/PGQ, which entered the SQL standard in 2023 and provides syntax for exploring relationships between nodes connected by edges. The PostgreSQL implementation was removed over unresolved issues.
The contributor Tom Lane had seen that coming. "At this point I'd be willing to bet dinner that if we ship it in v19 there will be post-release bug discoveries that are unfixable until v20," he warned in September.
What survives includes REPACK CONCURRENTLY, which reclaims disk space without the table lock that the VACUUM FULL operation requires. Eisentraut still expects "a great release", and added: "And it will be very robust, after all the additional scrutiny."
The project has been through longer delays than this one. Postgres was first proposed by Michael Stonebraker in 1986. Andrew Yu and Jolly Chen replaced its POSTQUEL query language with SQL in 1994, and in 1995 the database was made freely available and modifiable under a more permissive licence and renamed PostgreSQL. The features pulled this autumn are expected to appear in PostgreSQL 20, which until a few months ago was expected to contain no new features at all.
It is worth being precise about what changed between September and October, because it was not the code. The features were written by humans, reviewed by humans and committed. They passed. Then the reviewing improved, and the same unchanged code stopped passing. The forty defects were not introduced this autumn. They were noticed this autumn.
This newspaper therefore records a conclusion that will not appear in the release notes. The number of defects in a database is not a property of the database. It is a property of how hard somebody is looking at it.
The arithmetic is unforgiving. Forty reports arrived because forty reports could be found. Had the reviewers been marginally worse, the list would have been shorter, the overhead would have been affordable, the features would have shipped, and PostgreSQL 19 would have arrived in early October in a condition that everyone involved would have called finished.
Nor have the five years of post-release bug fixes been avoided. They have been pulled forward into October and renamed a delay. The total quantity of fixing is unchanged. Only its position in the calendar has moved, and the release date moved with it, which is the whole of the news.
The Department of Unnecessary Research notes the recommendation this implies and states it without enthusiasm. The surest way to ship PostgreSQL 20 on schedule is to review it less carefully than PostgreSQL 19. The bar has been raised above code that already cleared it, and there is no mechanism by which code already written can rise to meet it. Every version of this database that ever shipped on time did so because nobody had yet built the tool that would have stopped it.