Backports to the in-progress release jumped 61.8% year over year — 723 commits to REL_18_STABLE in 2025's window, 1,170 to REL_19_STABLE in 2026's. That is Robert Haas's whole argument for why PostgreSQL 19 is late, and my recount says he is right.
Haas, a PostgreSQL committer, wrote last month that Postgres 19 will likely slip to November — outside the project's usual mid-September to mid-October window — and that LLMs are the reason. Not because AI writes bad code, but because AI finds old bugs far faster than humans can review the fixes. He published six commit counts to back it up. I cloned the PostgreSQL repo and recounted all six, because a claim that specific deserves a recount, not a retweet.
The recount
Method, so you can repeat it: a bare, blob-filtered clone of github.com/postgres/postgres, then git rev-list --count <branch> --since=YYYY-04-08 --until=YYYY-09-25 for each branch and year. One quirk to state up front: git parses --until=YYYY-09-25 as September 25 at 00:00, so this window is April 8 00:00 through September 24 23:59. Haas says "between April 8 and September 25" without specifying the boundary convention, which is almost certainly why my numbers differ from his by a commit or two in most rows.
branch (window) Haas mine diff
master, 2025 1,037 1,035 -2 (-0.19%)
REL_18_STABLE, 2025 724 723 -1 (-0.14%)
REL_17_STABLE, 2025 248 247 -1 (-0.40%)
master, 2026 1,443 1,463 +20 (+1.39%)
REL_19_STABLE, 2026 1,169 1,170 +1 (+0.09%)
REL_18_STABLE, 2026 433 433 0 (exact)
Five of six reproduce within two commits; one reproduces exactly. The sixth — master in 2026 — is off by 20 commits, or 1.39%. I tried the obvious alternate conventions before concluding that: inclusive-of-September-25 counting, first-parent counting, and author-date instead of committer-date filtering. None of them lands on 1,443 either (inclusive counting gives 1,471; author-date gives 1,467). So either Haas counted from a slightly different snapshot or with a boundary rule I haven't guessed. I am reporting the gap rather than tuning my method until it matches, because the gap does not move any conclusion that matters:
backports to the in-progress release (REL_18 -> REL_19):
Haas: 724 -> 1,169 = +61.5%
mine: 723 -> 1,170 = +61.8%
backports to the prior release (REL_17 -> REL_18):
Haas: 248 -> 433 = +74.6%
mine: 247 -> 433 = +75.3%
master-only commits (master total minus stable-branch total):
Haas: 313 -> 274 = -12.5%
mine: 312 -> 293 = -6.1%
Every ratio that carries his argument survives. Backports to the release in progress jumped by roughly three-fifths; backports to the previous release jumped by roughly three-quarters. And the master-only arithmetic — the part of his post that reads oddly at first glance — also holds in direction: total master commits rose sharply (Haas +39.2%, mine +41.4%), but once you subtract the commits that also landed on the stable branch, the master-only remainder fell. That is his "declined slightly" line, and it is the most important number in the post: the project's new-feature work shrank while its bug-fix work exploded. My decline is smaller than his (-6.1% vs -12.5%), which follows directly from the master-2026 gap above, but the sign is the same.
The reverts check out to the day
Haas also names three large features reverted late in the beta period, between August 27 and September 15. All three revert commits are in the history with those exact dates:
2026-08-27 7612ae8ed8 Revert support for ALTER TABLE ... MERGE/SPLIT PARTITION(S)
2026-09-07 b1f106c80c Revert SQL Property Graph Queries (SQL/PGQ)
2026-09-15 a4b26b8f7c Revert UPDATE/DELETE FOR PORTION OF
And the release itself is still not out. The repo's v19 tags stop at REL_19_RC1 — there is no REL_19_0 tag as of this writing, on November 2, past the usual mid-October outer bound. The delay Haas predicted is, so far, the delay that happened.
What the numbers actually mean
Haas's mechanism has two steps, and only the first is an AI success story. Step one: LLMs made finding bugs in a 30-plus-year-old codebase vastly easier, so a huge number of people are now reporting bugs they found with AI, and committers are very, very busy fixing them. Step two: the fixes still need human review against PostgreSQL's standards, and humans did not get smarter between 2025 and 2026. Discovery scaled; review did not. Review time that would have gone into deciding what the release should contain got diverted into back-branches, which is why three major features got pulled weeks before release instead of months.
That framing reframes the usual AI-coding debate. The bottleneck was never "can AI find bugs" — a codebase with four decades of history contains bugs no human had time to find, and AI is good at exactly that kind of exhaustive search. The bottleneck is the human review queue, which is now the scarce resource in every mature project. If your project has a long history and a strict review bar, expect the same shape: a flood of plausible-looking bug reports, a growing backport count, and release dates that slip not because quality dropped but because quality control got busier.
Haas closes by saying he doesn't know how PostgreSQL catches up, and that every feature written from now on will be scrutinized by AI within hours. My recount adds one small, practical corollary: if you are going to cite commit counts in an argument like this, publish the exact command and boundary convention with them. My six numbers match his to within 1.4% — close enough to confirm the story, loose enough that someone else's recount could have produced a confusing headline instead. The story is solid. The citations should be as precise as the code.
Sources: Robert Haas, "Postgres 19 is late, and it's AI's fault" (October 2026) — https://rhaas.blogspot.com/2026/10/postgres-19-is-late-and-its-ais-fault.html (originally on neon.com). Commit counts, revert hashes, and tag state are from my own clone of github.com/postgres/postgres, counted with git rev-list as described above; Haas's figures are quoted from his post.
Top comments (0)