PostgreSQL 19 slips to November after AI-assisted review piles up bug reports

What the PostgreSQL project announced

The PostgreSQL Global Development Group released the first release candidate of PostgreSQL 19 on 15 October 2026 and set 19 November 2026 as the planned date for general availability. That is later than the project expected only a few weeks earlier. When it shipped Beta 4 on 24 September, the Beta 4 announcement said the release candidate should arrive in early October and that general availability might also happen in October.

The RC1 notice gives a narrow reason for the new date. The next scheduled update release for supported PostgreSQL versions, on 12 November, will include a large number of fixes, and the release team decided to fold those fixes into PostgreSQL 19 before it goes out. A second release candidate, RC 2, is planned for the same day, with general availability a week later unless another issue forces a delay.

The project's PostgreSQL 19 open items page lists the full schedule: feature freeze on 8 April, Beta 1 on 4 June, Beta 2 on 16 July, Beta 3 on 13 August, Beta 4 on 24 September, RC 1 on 15 October and RC 2 on 12 November, with general availability planned for 19 November. The bigger story is what happened between those dates: an unusually large set of features was taken back out of the release.

Which features were pulled

The Beta 4 release notes list the headline removals. The project reverted SQL/PGQ, the property graph query syntax added to the SQL standard in 2023; online enabling and disabling of data checksums; temporal updates and deletes through the FOR PORTION OF clause; and ALTER TABLE MERGE PARTITIONS and SPLIT PARTITIONS. It also removed three new functions for generating DDL for roles, tablespaces and databases, and reverted a change that forced LC_COLLATE to C in the postmaster process.

The project framed this as a reliability decision. The Beta 4 notice says the community believes that, first and foremost, PostgreSQL must be reliable, and that it also tries to keep a predictable release schedule, so it chose to remove features rather than hold the release for them. The removed work can come back in a later major version after more development and review.

According to The Register, which reported the delay on 16 October, between eight and ten significant features were dropped and are now expected to land in PostgreSQL 20 next year. The outlet also quoted a warning from long-time contributor Tom Lane about graph queries, made before the revert: he said he would be willing to bet dinner that shipping the feature in version 19 would produce post-release bugs that could not be fixed until version 20.

Why a committer blames better review, not worse code

The most detailed explanation comes from Peter Eisentraut, a PostgreSQL committer who was the developer or committer of some of the reverted work. In a blog post on 9 October he wrote that about eight to ten significant features had been reverted after beta began, against perhaps one revert in a normal cycle, and that some were pulled quite late.

He offers several causes and says it is probably a mix. Some of the code may simply not have been good enough, and some reverted features had significant architectural defects that would have been hard to fix quickly during beta. It could also be a coincidence, with the project taking on several features that proved too hard to finish in time.

The part that drew attention is his description of the long tail. Alongside the serious problems there were many relatively harmless edge-case issues. In the past, he wrote, most of those would have surfaced slowly and been fixed over the following five years. With LLM-assisted code review they are found much faster, and a developer can end up staring at a list of around forty defect reports. Even if each needs only a three-line fix on average, every report carries fixed overhead, and the schedule runs out.

Eisentraut argues that the effective quality bar was raised after the features were written. Most of the affected work was committed long ago, when LLM-assisted review was much less useful, and was then judged against what the newer tools could find. He also says the problem is not vibe coding, since the code predates that practice, and expects it to sort itself out in future cycles unless review tools keep improving at the current rate.

The Vulnpocalypse and a thin beta

Eisentraut ties the timing to what he calls the Vulnpocalypse. From April, when the PostgreSQL 19 feature freeze began, to August, when the most recent security release shipped, many senior developers were busy fixing security issues. That cut into the extra review and testing that normally happens during beta, which picked up again only in August, and he thinks that is why so many problems appeared so late.

The surge in vulnerability reports is part of a wider shift that AI Lookout has tracked from the defender side. Large organisations are now hiring people just to work through model-found flaws, as with Bank of America's 1,000 extra contractors, and tools such as Anthropic's OSS Scanner send model-written bug reports to open-source maintainers. PostgreSQL's beta shows the same pressure landing on a volunteer-heavy project with a fixed release calendar.

He also points to the system's complexity. A new SQL feature may need to work with domains, domains over composite types, dropped and re-added columns, partitions detached and reattached with a different column order, and views called from security-definer functions inside triggers. Nobody can enumerate those cases by hand, he wrote, but LLM-assisted fuzzing can find problems with them very quickly, so it probably needs to become part of feature development. PostgreSQL's promise that everything works with everything is part of its appeal, and he does not want to give it up, but it imposes a real cost on new features.

What is still in PostgreSQL 19

The release is still substantial. Eisentraut singles out REPACK CONCURRENTLY, which reclaims table space without the long lock that VACUUM FULL takes; logical replication of sequences, itself a feature reverted in an earlier cycle; and planner hinting through pg_plan_advice. He expects the release to be very robust after all the extra scrutiny.

The RC1 notes show where the late fixing effort went. Changes since Beta 4 include several fixes for REPACK (CONCURRENTLY), several for pg_plan_advice, fixes for new planner optimisations that depend on whether an expression can be NULL, fixes for automatic logical replication when wal_level is set to replica, a postgres_fdw statistics import change, fixes for parallel autovacuum, and a correction so that COPY with FORMAT json uses the query's column names as keys.

Upgrading from earlier versions still requires a major-version strategy such as pg_upgrade or a dump and restore. Eisentraut notes that a few months ago he had suggested PostgreSQL 20 might contain no new features at all, only fixes. Instead, version 19 has roughly half the major features once expected, and several mostly finished ones are already queued for version 20.

What it means for teams using AI code review

The PostgreSQL case is a public example of something many engineering teams are about to hit. Products such as Claude Code Review make it cheap to run deep review on every change, and older code that passed human review can suddenly produce dozens of findings. Research on coding agents has already suggested that review, not code generation, is becoming the bottleneck.

The practical lesson from Eisentraut's account is about capacity, not accuracy. If a review tool finds forty real but minor defects in a feature, someone still has to reproduce each one, write a test, agree on a fix and land it. Teams that switch on AI review late in a release cycle may need to budget for that triage, decide which classes of finding block a release, or run the tools earlier, while features are still being built.

Open-source projects are also adjusting their rules. The Linux kernel recently moved to drop its Assisted-by tag for AI tools, with Linus Torvalds saying contributors must understand their code whatever tools they use. Eisentraut points to another option PostgreSQL has discussed for years: committing features with an experimental status and maturing them in the main tree, which might have saved some of this year's reverted work if the project had agreed how to do it.

Limits and open questions

Eisentraut is explicit that these are his opinions and that the affected developers have not had time to reflect fully. The official release announcements do not mention AI at all; they cite reliability, the release schedule and the size of the November update release. Attributing the reverts mainly to LLM-assisted review would overstate what the primary sources say.

There is also no public count of how many of this cycle's defect reports came from LLM-assisted tools, which tools were used, or how many findings were false positives. The forty-report figure is an illustration from one developer's experience, not project-wide data, and AI Lookout has not reviewed the mailing-list threads behind each revert.

The 19 November date can still move. The RC1 notice says it holds unless an issue is found that requires a delay or another release candidate. The next things to watch are whether RC 2 ships on 12 November as planned, which reverted features return in PostgreSQL 20, and whether the project formalises experimental features or LLM-assisted fuzzing as part of how new work is developed.