PostgreSQL 19 Delayed to November 2026 After LLM Code Review Forces 8–10 Feature Reverts

PostgreSQL 19 has been delayed to roughly November 19, 2026, and between eight and ten significant features have been pulled from the release, because LLM-assisted code review found more defects than the project's human committers could triage and fix before the deadline. The PostgreSQL Global Development Group attributes the reverts to a quality bar that rose mid-cycle rather than to AI-written code.

PostgreSQL 19 slipped from late September/early October to about November 19, 2026

The PostgreSQL Global Development Group delayed PostgreSQL 19 from its original target of late September or early October 2026 to an expected general availability date around November 19, 2026. Alongside the delay, developers dropped between eight and ten significant features from the release, postponing them to PostgreSQL 20.

Peter Eisentraut, a leading PostgreSQL committer and vice president at EDB (a PostgreSQL support and consultancy), attributed the unusually high number of reverts at least in part to the LLM code reviews developers were running.

LLM-assisted review raised the quality bar after features were already committed

Eisentraut's explanation, published in a blog post titled "The reverts will continue until morale improves" on October 9, 2026, splits the reverted work into two categories.

The first category is genuine architectural defects. Some reverted features had significant architectural problems that would have been hard to fix "quickly and during beta."

The second category is the long tail. LLM-assisted code review uncovered many "relatively harmless issues involving various edge cases" that in previous cycles developers might not have noticed until much later — typically surfacing as bug fixes over the five years following a launch. Eisentraut described the resulting workload:

"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. 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."

The timing problem is that PostgreSQL 19's major features were written when LLM-assisted code review was less capable than it is now. The review tooling improved during the months leading up to the launch, after the code was already committed. Eisentraut framed this as a one-off mismatch:

"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."

The reverts are not "vibe coding," according to PostgreSQL committers

Eisentraut explicitly rejected the interpretation that AI-generated code caused the reverts. He stated that the reverts were not down to "vibe coding" in development, because the technique was not available when most of the new features were written. The defects were found by AI review of human-written code, not introduced by AI authorship.

SQL/PGQ is among the features pulled from PostgreSQL 19

One of the features removed from PostgreSQL 19 is support for SQL Property Graph Queries (SQL/PGQ), which became part of the SQL standard in 2023. SQL/PGQ provides syntax for exploring relationships between nodes connected by edges. PostgreSQL's implementation was removed over unresolved issues.

PostgreSQL contributor Tom Lane had warned about the feature before the revert. In September 2026 he said:

"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."

PostgreSQL 19 still ships REPACK CONCURRENTLY and is expected to be robust

Despite the delay and the reverts, Eisentraut said PostgreSQL 19 will still be "a great release." One confirmed highlight is REPACK CONCURRENTLY, which avoids the table-lock VACUUM FULL operation used to reclaim disk space. He also argued the extra scrutiny has a benefit: "And it will be very robust, after all the additional scrutiny."

The reverted features are now expected to land in PostgreSQL 20

The features reverted from PostgreSQL 19 will likely make it into PostgreSQL 20. That reverses a plan announced only a few months earlier: developers had expected PostgreSQL 20 to contain no new features, just bug fixes. PostgreSQL 20 is now likely to carry the new features left over from the earlier release.

PostgreSQL's history explains why the project is conservative about shipping

PostgreSQL was first proposed by Michael Stonebraker in 1986. In 1994, Andrew Yu and Jolly Chen replaced the query language POSTQUEL with SQL, and in 1995 the database was made freely available and modifiable under a more permissive license and renamed PostgreSQL. It has since become the most popular database among professional developers, driven by the services the big three hyperscalers built on it and by the range of wire-compatible distributed systems available.

Commenters argue QA, not coding, is the AI-era bottleneck

Hacker News discussion of the delay converged on a single theme: AI makes defect discovery cheap and defect resolution expensive, which turns quality assurance into the constraint on release schedules.

One commenter argued that the bugs AI review surfaces are not the kind an LLM can fix with a button press, because they require design judgment:

"Some conjecture on my part, but I imagine that the bugs being found are not the kind you can just press a button on the LLM to fix anyway, but are instead the sort of bugs which require the reviewer to deeply consider design tradeoffs, of which I believe there are simply more in a DB or programming language codebase."

Another commenter framed the shift as a loss of plausible deniability: once tooling can comprehensively discover bugs and missing test cases, teams can no longer ship barebones features and defer the consequences. The result is more time spent per feature and a release that looks less productive even though it is better.

A third commenter made the case that QA is where the durable value sits:

"QA is becoming the blocker for projects in an AI era, and the real source of value. AIs can lay down a good base of testing but I see even frontier models still need help with testing because they are basically as bad as humans in terms of testing only what comes to mind, if not even a touch worse."

The same commenter argued this entrenches SaaS rather than killing it, because a small business that can prompt a front-office system into existence still will not want to QA it — and the QA load grows with the amount of code. The comparison to PostgreSQL is direct: "even if you can prompt a database into being today, which you can, you can't prompt something into existence that has been tested and QA'd like Postgres."

Counterpoint: AI can find an effectively infinite number of bugs

A recurring objection in the discussion is that AI review has no natural stopping point. As one commenter put it, "AI can literally find an infinite number of bugs. There are always more bugs to be found, whether they would have ever affected any actual real world case or been noticed or not."

That leads to the obvious question raised by another commenter: if the current release has this many latent bugs, so does the version already in production. "Doesn't that just imply the existing version of Postgres also probably has more bugs than humans can fix? Just release it. Software is never perfect and always a work in progress."

Counterpoint: AI bug reports still need human triage

Several commenters cautioned that raw AI output is not a defect list. One cited a prior case in which an AI tool reported 82 bugs in the Linux kernel and only six to eight turned out to be real — the rest were already fixed, fixed in the newest version, or fabricated. The stated conclusion: skepticism is warranted until humans sift the pile.

Others drew the same line as a process rule rather than a reason to stop:

"Using AI to find bugs (rather than write them) is a great use case IMO. Even if you have skilled reviewers, more eyes are almost always better. Just don't post the unedited AI 'bug report' as an issue please. A human should make sure it's actually a real problem before dumping it on devs."

One commenter also noted a potential conflict of interest in the framing, pointing out that EDB, Eisentraut's employer, markets AI-oriented Postgres products, and asking rhetorically whether nothing in PostgreSQL ever worked before AI.

The deeper claim: PostgreSQL's test suite, not AI, is the root cause

A commenter working on a Rust rewrite of PostgreSQL offered the most technically specific counter-narrative: AI is not creating bugs, it is exposing a test suite that was never designed to hit edge cases.

"For the most part, Postgres relies on individual regression tests to test each feature. While regression tests are great for making sure features don't break ... they actually aren't that great hitting the edge cases (passing a string that's over 2MB to a specific function will trigger a buffer overflow and crash your DB)."

That commenter reported finding roughly 50 bugs in core PostgreSQL while building the rewrite, using AI to scale techniques that predate AI — deterministic simulation testing, differential coverage-guided fuzzing, and formal verification. The most aggressive example: a compiler that translates C and Rust functions into Lean, with an LLM writing proofs that the two implementations are identical. At the time of writing, 10.5% of the codebase (67k of 640k lines) had been verified equivalent, with findings as fine-grained as a parsing function where PostgreSQL trimmed spaces using isspace() while the rewrite trimmed only ASCII whitespace.

What the PostgreSQL 19 delay signals for AI-assisted engineering

The PostgreSQL 19 delay is an early, concrete example of a pattern that is likely to repeat across mature open source projects: AI review lowers the cost of finding defects far faster than it lowers the cost of resolving them, so the binding constraint moves from writing code to adjudicating findings. PostgreSQL's response — reverting features to the next major version rather than shipping known-defective work — is the conservative choice, and it is consistent with the project's long-standing practice of minimizing risky changes and relying on heavy human review.

Eisentraut's own prediction is that the effect is transitional: the mismatch only exists because review capability improved after the code was written. If LLM review capability keeps improving at its current rate, future development cycles will be written under the new quality bar from the start rather than retrofitted to it.