A PostgreSQL core team member says LLM-assisted code review is one reason about 8 to 10 features were pulled from version 19

PostgreSQL 19, the next major version of the open-source database, now has a planned general-availability date of 19 November 2026, according to the PostgreSQL Global Development Group's release-candidate announcement on 15 October. Separately, in a blog post on 9 October, Peter Eisentraut, a long-time PostgreSQL committer and member of the project's core team, wrote that "about 8 to 10 significant features, depending on how you count" had been reverted from the version 19 branch after the beta period began, and named LLM-assisted code review as one of several likely reasons.

The schedule, in the project's words

When the first beta shipped on 4 June, the project said it would release more betas and release candidates "until the final release around September/October 2026."

The first release candidate (RC 1) came out on 15 October. That announcement says: "The planned date for the general availability of PostgreSQL 19 is November 19, 2026." It also adds a condition: "Unless an issue is discovered that requires a delay or an additional release candidate, PostgreSQL 19 should be made generally available on November 19, 2026."

The project gives its own reason for a second release candidate. The next update release for supported versions, due on 12 November, "will include a large number of fixes", and "the release team decided to include these fixes in PostgreSQL 19 before its general availability." RC 2 is planned for the same day. The announcement does not mention the reverts or AI review.

What Eisentraut wrote about the reverts

Eisentraut says he was the developer or committer of some of the reverted features. He also says "these are just my opinions at this point." Some reverts are normal: "Having some reverts is not unusual, maybe one per cycle could be expected."

He does not give a single cause. "It’s probably a combination of these, and a different combination in the case of each reverted feature," he writes, then lists several factors:

• The code itself. "Maybe we just didn’t do a good enough job."
• Coincidence. The developers may have taken on several features that turned out too hard to finish in time.
• LLM-assisted code review. Some reverted features had "significant architectural defects", he writes, but there was also "a long tail of relatively harmless issues involving various edge cases." In the past many of these would have been fixed over the following five years. Now, "with LLM-assisted code review, these kinds of things can get found much faster, and then you’re staring at a list of like forty defect reports." Even small fixes carry "a fixed overhead", he writes, "and then you run out of time."
• Less review during beta. Because of what he calls the "Vulnpocalypse", many senior developers were busy with security fixes from roughly April to August, so the usual review and testing during beta was reduced. That is "possibly why" many issues were found late. He adds that "the community preferred trying to stick to the release schedule rather than delaying" to get more fixes in.
• System complexity. Some features interact with so many other features that no one can test every combination by hand, though he writes that "LLM-assisted fuzzing can find problems with this really quickly."
• No "experimental" status. There is still no way to commit a feature as experimental and mature it in the main tree.

On AI review specifically, he writes that most of the reverted features "were written a long time ago when LLM-assisted code review was not as useful as it is now," so "the effective quality bar has been raised after the time the feature was written and committed." He expects it to pass: "Unless the capabilities of LLM-assisted code review keep improving at the current rate, this situation should sort itself out for future development cycles." He also writes that, as far as he can tell, the situation is mostly not due to "vibe coding", because the code was written before that was possible.

He does not name any AI tools or models in the post.

What ships

Eisentraut writes that "PostgreSQL 19 will still be a great release", naming REPACK CONCURRENTLY, logical replication of sequences and planner hinting with pg_plan_advice. He adds: "I’m confident that many of the reverted features will come back before too long", and says a few features are already queued for PostgreSQL 20.

The Register covered the story on 16 October with a headline saying the release was delayed after AI reviewers found more bugs than humans could fix. Neither the blog post nor the project's announcement directly links the new date to AI review.

Why it matters

On our reading, this is a first-hand account from one senior developer on a major open-source project, offered as "just my opinions", of what happens when AI-assisted review is applied to code written when it was "not as useful as it is now". In Eisentraut's account, the AI review found problems faster than people could fix them. He expects it to be a catch-up that settles, unless AI review keeps improving at its current rate, and calls it one factor among several. The official 19 November date still carries the project's own condition: "Unless an issue is discovered that requires a delay or an additional release candidate".