PostgreSQL 19 will ship without about ten of its new features

A ranking Claude was asked to make

On August 25, Robert Haas posted a message titled "scary patch contest" to the PostgreSQL developers' mailing list. PostgreSQL is the open-source database born at Berkeley in the 1980s. Haas is a committer, one of the people allowed to merge code into the project. He asked Claude to name the version 19 features that look scariest, based on the number and nature of the bugs fixed since the feature freeze. He published the ranking, noting that he had trimmed a few particularly savage remarks from the machine.

Six candidates. The most-fixed, REPACK, a maintenance command, drew 28 fixes. Checksums that can be switched on while the database runs, about 25. Graph queries, 17. Haas doesn't take a side: he asks whether some of these should be pulled from the release before it ships.

The same day, Tom Lane, another committer, said he'd bet a dinner that if graph queries stay in 19, they'll carry bugs that can't be fixed before 20. His argument has nothing to do with AI. Patches still under discussion require touching the database's internal catalog.

About ten features sent back

On September 7, graph queries were pulled. Added to the SQL standard in 2023, they let you walk through relationships, such as a network of friends or a supply chain. The removal reverts 47 changes: the original feature and 46 follow-up tweaks. Peter Eisentraut signed it, and he is one of its two authors.

It isn't alone. In a post published on October 9, Eisentraut counts roughly 8 to 10 significant features pulled from 19, "depending on how you count," some of them very late in the beta. You'd normally expect maybe one per cycle. The project's public history shows, among others, GROUP BY ALL, a grouping shortcut (pulled July 17), merging and splitting partitions (August 27), and updates over a slice of a time period (September 15).

The schedule slipped too. On September 28, the release team announced the final version for October 29. On October 10, it pushed it back to November 19. That is a planned date, valid unless a problem is discovered before then, according to the announcement of the first release candidate, out on October 15.

Versions 16, 17 and 18 all shipped in September. Since 2016, no major version had come out after October 18.

The bar went up after the paper was handed in

Why so many removals? Eisentraut offers several explanations, probably combined and different for each feature. He stresses that these are only his opinions. The first is blunt: maybe the code just wasn't good enough.

The one the press picked up is another. Setting aside the big architectural flaws, he describes a long tail of fairly minor problems, edge cases that would once have been fixed bit by bit over five years. With LLM-assisted review, they all surface at once. You can end up, he writes, staring at a list of something like forty defect reports. Even if each needs only three lines of fix, each carries a fixed cost, and time runs out.

Hence his line: the quality bar was raised after the code was written. It's like changing the grading scale after the exams have been handed in. Most of the removed features, he says, were written a long time ago, when LLM review was nowhere near as useful.

Reviewed with AI, not written by it

The distinction matters. Eisentraut rules out "vibe coding," the code churned out in conversation with an AI, but carefully: for the most part, as far as he can tell, that isn't where this comes from, since the code was written well before that was possible. Daniel Gustafsson, another committer, was already saying so in late August: most of the big features in 19 were written, reviewed and tested before AI tools were available, or even remotely as good as they are today.

In Haas's thread, the others talk about impressions, not measurements. Nathan Bossart has a feeling that LLMs help find more. Richard Guo expected AI help to make features more stable by the freeze, and notes that it doesn't seem to have. Amit Kapila sees a long-term gain in stability, at the price of more fixes in the short term.

Eisentraut gives an example of something no human tests by hand: a query on a domain defined over a composite type, in a partition that was detached and reattached with a different column order, called from a trigger. Nobody can list all such cases, he writes. LLM-assisted fuzzing, which bombards the code with generated inputs, can find problems there very quickly.

The tool is no oracle, though. Paul Jungwirth, author of the period-based updates, says he asked Claude for a cross-testing plan. Claude wrote tests without finding a single new bug. Others have since found two.

The delay has a different official reason

That leaves the schedule slip, which The Register blames on AI reviewers. The official October 10 message gives another reason: the volume of fixes added to the versions already in service. The team wants to fold them into a second release candidate, on November 12, the day of the quarterly update, before the final release. The removals, for their part, were meant precisely to keep to the schedule: rather than delay to fix things, the community chose to hold the line, Eisentraut writes.

A thread does link the two, though. From April to August, many experienced developers were busy fixing security flaws, he says, which cut into the usual beta review. He calls that period the "Vulnpocalypse." In June, on the oss-security mailing list, the word described the wave of AI-found flaws people saw coming.

PostgreSQL's security page lists 44 flaws dated 2026, 28 of them fixed in August, against 7 in each of the three previous years. It does not say who found them.

What 19 keeps

The release keeps REPACK CONCURRENTLY, which reorganizes a table without locking it, and hints for steering the query execution plan. It will be very robust, Eisentraut promises, after all this extra scrutiny. Version 20, which he said a few months ago might have no new features at all, already inherits features that are 80% ready.

At Linux, one patch in ten now declares itself AI-assisted, mostly from regulars doing repairs. At PostgreSQL, the machine finds regulars' blind spots, and according to Eisentraut, the bottleneck becomes the time of the humans who have to fix them.

Eisentraut thinks the situation should sort itself out over the next few cycles. On one condition, which he sets himself: that LLM review stops improving at the current pace.