PostgreSQL 19 Slips to November 19 After Late Reverts, and AI Code Review Is Only Part of the Story

PostgreSQL 19 will not ship in October. On October 10 the project’s release team moved general availability to November 19, and the October 15 release candidate announcement repeats that date. The reason the team gives is the volume of fixes: “Given the volume of fixes that have been added to the back branches,” Jonathan Katz wrote to the pgsql-hackers list for the release team, it wanted those fixes in a second release candidate on November 12 before general availability.

The Register’s report on the delay carries the headline “Postgres 19 delayed after AI reviewers find more bugs than humans can fix”. The release team’s two notices do not mention AI. That explanation comes from a blog post by Peter Eisentraut, a member of the PostgreSQL Core Team, who wrote on October 9 that about 8 to 10 significant features had been reverted from the 19 branch after beta began, and that LLM-assisted code review was one of several likely causes. We checked the claim against the project’s git history, mailing list and release pages. AI-assisted review is visible in that record, but the public reasons for the largest revert are about design, not AI.

What the project has said

Katz’s October 10 message says RC 1 would go ahead on October 15 as planned and that general availability moves to November 19, “one week after the planned scheduled update release”. It adds: “We know this has been an atypical major release cycle, but we want to ensure we keep delivering a PostgreSQL that’s stable and reliable, and we’ve made these decisions around that goal.”

The RC 1 announcement says the November 12 update release “will include a large number of fixes”, and continues: “Because of this, the release team decided to include these fixes in PostgreSQL 19 before its general availability.” It also hedges the new date: “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.” Neither notice says what produced the fixes or mentions reverts. The project’s roadmap page still says, as of this writing, “This release is planned for October 2026.”

What was pulled, and how large it was

Eisentraut, who is on the Core Team list and committed two of the large reverts himself, wrote that “Having some reverts is not unusual, maybe one per cycle could be expected”, but that this time “about 8 to 10 significant features, depending on how you count” came out, “some of them quite late in the beta period”. To see how the cycle compares, we counted revert commits on each release branch of the postgres/postgres mirror: commits whose subject begins with “Revert”, dated between the beta 1 tag and the general availability tag (for 19, the RC 1 tag).

The tag dates fall a few days before each public release. By that count the 19 cycle is only slightly above 18, 16 revert commits against 14, so the number of reverts does not by itself set this cycle apart. Counted over each release’s whole development cycle, from the commit that stamped the tree for it (2023-06-29, 2024-07-01 and 2025-06-29) to the GA tag, or to October 17 for 19, the totals are 45 for 17, 41 for 18 and 37 for 19 so far. We could not reproduce the counts in Snowflake’s September 16 post, 53 reverts for 19 and about 44 for 18, from commit subjects, so we do not use them. That post also dates the start of the 19 beta to June 2025, while the beta 1 tag is dated June 1, 2026.

Eisentraut’s point is about significant features rather than commit counts, and the four largest reverts are large: each unwinds between 14 and 47 commits, 114 in all. They landed between August 27 and September 16, 87 to 107 days after beta 1.

Smaller reverts since beta 1 include GROUP BY ALL (July 17), non-text output formats for pg_dumpall (June 18), fast defaults for domains with non-volatile constraints (June 8) and three pg_get_*_ddl() functions (September 13). The commit counts for SQL/PGQ and the partition feature match those in Command Prompt’s September 8 post.

What Eisentraut says caused it

His post is explicit that these are “just my opinions at this point”, and he does not name one cause: “It’s probably a combination of these, and a different combination in the case of each reverted feature.” The combination he describes has several parts.

• Code quality and coincidence. Maybe the code “was just not good enough”, or the project took on several features that turned out too hard to finish in time.
• Architecture plus a long tail. Some reverted features had significant architectural defects, and others had many small edge-case issues. Of the long tail he writes: “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.” Because most of the reverted code was written when such review was less useful, “the effective quality bar has been raised after the time the feature was written and committed.”
• Security work. Because “many senior developers were busy” with security fixes between April (“the start of feature freeze for PostgreSQL 19, and also the start of the Vulnpocalypse”) and August, “the usual additional review and testing that happens during the beta period was reduced”. He does not define the term in the post.
• Complexity and process. Features have to work with everything else in PostgreSQL, and the project has not yet found a way to commit features with an “experimental” status.

He rules out one cause: “vibe coding”, because the code “was written well before that was a possibility”. He also writes that “the community preferred trying to stick to the release schedule rather than delaying to get more fixes in”, a day before the release team moved the date. The Register’s article body is closer to his text than its headline is: it says he thought the reason “could be at least in part attributed to the LLM code reviews used by developers.”

Where AI shows up in the commit log

We searched the messages of the 3,464 commits on master from October 1, 2025 to October 16, 2026 for AI tool names, vendors and review methods: Claude, Codex, GPT, Anthropic, OpenAI, Xint, LLM, “AI assisted” and similar. In that window 45 commit messages name one. The first, dated February 9, is a pgcrypto fix credited to “Team Xint Code as part of zeroday.cloud”; Xint Code is described by a PostgreSQL community blog as an autonomous AI code-analysis tool. The next two are dated April 22, the month Eisentraut dates the start of the Vulnpocalypse. The counts are keyword hits, not a measure of how much AI the developers use: they include finder credits, authorship notes and passing mentions, and they miss anything a committer did not write down.

The CVE counts come from PostgreSQL’s security page and match the CVE-tagged items in the release notes for the August release, May and February. The August notes mention 31 CVE numbers, but three are references to earlier fixes. The commits naming AI tools bunch up just before the two big security releases: 11 on May 11, three days before the May 14 release, and 8 on August 10, three days before August 13.

The credit lines are specific. Ten commits on May 11 say “Reported-by: Xint Code”. Three on August 10 say “Reported-by: Amy Burnett (OpenAI Codex Security)”, and three more say “Reported-by: Ben Morris in collaboration with Claude and Anthropic Research”. Four on August 17 and 18 say “Reported-by: Claude Code (via Noah Misch)”. Two later ones, on September 24 and October 6, say “Reported-by: Anthropic OSS program”. Committers also disclose their own use. Tom Lane’s July 27 fix to FOR PORTION OF says: “Full disclosure: an earlier draft of this patch was made with Claude Opus 4.8.” And contributions arrive that way too: on August 10 Michael Paquier committed a patch for the cryptohash code with the note “The submitted code was clearly AI-generated”, and says he cleaned it up to match the project’s style.

One revert has an AI trail

The clearest chain in the log leads to the online data checksums revert. On September 14, Daniel Gustafsson committed four changes for that feature that credit AI-assisted review: “Issues found by Noah and Robert using AI assisted review with Claude” (commit), “Found by Noah using AI assisted review with Claude” (commit), “Found by Noah using AI assisted review with GPT” (commit) and, in a documentation update, a set of corrections “found via manual as well as LLM-guided review” (commit). Two days later the feature was reverted. The revert message cites the number of post-commit fixes and the risk of more bugs after release. It does not mention AI.

The biggest revert has a design rationale

For SQL/PGQ, the revert with the most commits, the public rationale does not involve AI. The revert commit links a hackers thread that opens with Andres Freund’s August 22 questions about how property graphs are represented in the catalogs and handled by pg_dump. On September 2 Melanie Plageman, who is on the 19 RMT according to the project’s wiki, wrote under an “[RMT hat]” label that the team had “serious concerns about the number of design issues with either recently posted patches or without consensus on behavior.” She added that “we feel it would be better to revert this in 19” and that doing so “would make it easier to fix these things properly in 20”. We found no mention of an AI tool anywhere in that thread.

An outside analyst, Josh Andrews of Dorian Insights, posted a similar analysis to pgsql-hackers on September 28. He reported “26 stable-branch fix commits disclose AI involvement in the commit message, all since April 2026”, and also that “Total list traffic and total bug-report volume show no significant changes from historical volume.” His scope differs from ours, and his CVE counts for May and August, 14 and 29, are higher than the 11 and 28 on the project’s security page, so we cite his figures only as his. The same squeeze shows up elsewhere: curl fixed a record 24 vulnerabilities in one release, 18 of them from an AI-assisted audit; Anthropic’s OSS Scanner emails maintainers model-generated reports with no human review, and the “Anthropic OSS program” now appears in PostgreSQL’s credit lines; Google stopped taking product bug reports for its open-source bounty, citing automated submissions; and a Harvard study of 718 firms found code output rising while pull requests waited longer to merge.

What it means if you plan around PostgreSQL 19

• Test the release candidate, and plan on November 19. RC 1 is out, RC 2 is planned for November 12, and the date holds only “unless an issue is discovered that requires a delay or an additional release candidate”.
• Do not plan around the pulled features. The 19 release notes, marked as of October 9, do not list SQL/PGQ, GROUP BY ALL, FOR PORTION OF or the partition merge and split commands. Eisentraut writes: “I’m confident that many of the reverted features will come back before too long.” The RMT’s SQL/PGQ message points to PostgreSQL 20.
• Features that remain. The notes do describe REPACK, pg_plan_advice, ON CONFLICT DO SELECT and IGNORE NULLS, and the RC 1 announcement lists fixes for REPACK (CONCURRENTLY), pg_plan_advice and parallel autovacuum.
• If you run PostgreSQL 14, its final release is scheduled for November 12, a week before 19’s planned general availability date.

What the record does not show

The public record cannot say how many of the late bugs were found by AI review. Commit credits depend on committers choosing to name a tool, and the release team has not tied the delay to any cause beyond the fix volume. Eisentraut’s own forecast is conditional: “Unless the capabilities of LLM-assisted code review keep improving at the current rate, this situation should sort itself out for future development cycles.”

Sources and method: the release team’s message and the RC 1 announcement, the roadmap and versioning pages, the contributors page and the 19 release notes on postgresql.org, plus the wiki page on the Release Management Team; Eisentraut’s post; The Register’s report; Snowflake’s and Command Prompt’s posts; the SQL/PGQ thread, read in full from the archive; and Andrews’s message. The revert and AI-mention counts come from a treeless clone of the GitHub mirror taken on October 16, with its master branch at a commit dated October 16, 15:26 UTC. We used committer dates, counted revert-titled commits on REL_17_STABLE, REL_18_STABLE and REL_19_STABLE, and searched the commit messages of all of master for the terms above, with whole-word matching so that mailing-list message IDs do not match. The CVE counts were checked on October 16 and may change.

Related coverage: curl’s record 24-vulnerability release, Anthropic’s OSS Scanner and the Harvard study on AI coding agents and code review.