LLMs flooded PostgreSQL with bug reports and delayed its release

The reason: a surge of bug reports found by large language models, which has overwhelmed the project's human committers and forced late reverts of major features.

MERGE PARTITION/SPLIT PARTITION—were reverted between August 27 and September 15, an unusually late date for such pulls. Haas attributes this disruption to LLMs making it "vastly easier" to find bugs that previously escaped detection.

The numbers are stark. Between April 8 and September 25, 2025, there were 1037 commits to PostgreSQL's master branch and 724 commits to REL_18_STABLE. In 2026, the same period saw 1443 commits to master and 1169 commits to REL_19_STABLE—a more than 60% jump in back-patched commits despite slightly fewer master-branch commits. The bleed into older releases was even sharper: 248 commits to REL_17_STABLE in 2025 versus 433 commits to REL_18_STABLE in 2026, a 74% increase. Haas writes that committers were likely about as conservative as in prior years, but "a lot more of the mistakes they made were quickly found by LLMs."

A Hacker News commenter who did AI-assisted bug-hunting in PostgreSQL reported finding "hundreds of candidates" including serialization anomalies, foreign key integrity issues, planner correctness bugs, and CVE-worthy vulnerabilities, ultimately triaging down to a dozen or two reports. The commenter noted: "Now imagine the entire world doing this."

LLMs have inserted a new producer into this system without adding a corresponding reviewer. But Haas notes that LLM-drafted fixes "aren't always correct or compliant with PostgreSQL standards," so they still require human review. The humans, as he puts it, "have not gotten any smarter between 2025 and 2026." The result is a queue: more valid bugs enter the system than committers can process, and time spent on back-branch fixes displaces time needed for release review.

This creates a specific pressure on the project's design constraint of human-gated commits. PostgreSQL's quality depends on committer review, not automated merge. When bug discovery accelerates but bug validation does not, the bottleneck moves from "find bugs" to "verify and integrate fixes." The late reverts of major features suggest that committers lacked bandwidth to properly evaluate whether those features were stable enough to ship, because that bandwidth was already consumed by back-branch work.

The trade-off is between openness and review capacity. Each valid bug report demands committer attention; each invalid or low-priority report demands some attention to reject. A Hacker News commenter raised the distinction: high-quality reports with viable fixes are manageable, even welcome, but "low quality contributions" waste time. Another commenter added a further dimension: "Not every valid bugfix is equivalently urgent," and "burdening maintainers with pedantic bugs" is a cost that AI is "absolutely awful at" assessing.

The incentive structure compounds this. LLM-assisted bug hunters are rewarded for finding and reporting bugs—quantity is visible, urgency is not. Committers are rewarded for stability and correctness, which requires judging which bugs matter. If a system separates discovery from validation, and discovery becomes cheap while validation remains expensive, then validation becomes the constraint and anything dependent on it—release schedules, feature retention, committer sanity—bends or breaks.

Haas's open question is whether this is a temporary catch-up or a permanent condition. Forty years of accumulated bugs, now findable, implies a long queue. If a project has finite committer hours and LLMs can generate reports faster than those hours can process them, then the project must either expand review capacity, narrow the intake funnel, or accept that innovation pauses while the backlog clears. PostgreSQL has chosen quality so far, delaying the release. Whether that choice remains sustainable as the "entire world" picks up LLM-assisted bug hunting is the unresolved test.