# Postgres 19 Is Late Because LLMs Found Too Many Bugs, Says Committer Robert Haas

> Source: <https://explainx.ai/blog/postgres-19-delayed-llm-bug-reports-robert-haas-backpatch-commits-2026?utm_source=rss&utm_medium=feed&utm_campaign=blog>
> Published: 2026-10-31 00:00:00+00:00

**PostgreSQL 19 is late, and one of the people who builds it says AI is why.** Robert Haas, a Postgres committer, wrote in a post published on [Neon's blog](https://neon.com/blog/postgres-19-is-late-and-its-ais-fault?ref=explainx) on October 21, 2026 that "LLMs happened": a flood of bug reports found with language models consumed committer time, forced three large features out of the release late in beta, and pushed the release past its usual mid-October window. His own estimate is that Postgres 19 "most likely won't be released until November."

The post resurfaced on Hacker News on October 30, which is why it is circulating now. It is worth reading carefully, because it is rare to see maintainers of a major database put numbers on how AI bug-hunting changes the workload of an open-source project. This article separates what Haas measured, what the PostgreSQL project itself has published, and what remains his interpretation.

## TL;DR: the claim in one table

| Question | Answer | 
|---|---|
| Who is making the claim? | Robert Haas, Postgres committer, via Neon's blog (Oct 21, 2026) | 
| What is the claim? | LLM-found bugs raised the fix workload, delayed the release and forced late reverts | 
| Is Postgres 19 out? | Haas expects November; the project's site shows RC 1 released October 15, 2026 | 
| Which features were reverted? | SQL/PGQ, online data checksums, FOR PORTION OF, MERGE/SPLIT PARTITIONS (per the Beta 4 notice) | 
| Key number | Back-patched commits to the in-progress release up more than 60% year over year | 
| Does the project blame AI? | Not in the Beta 4 notice, which cites reliability and a predictable schedule | 
| Is the causal link verified? | The commit counts are public; the link to LLMs is Haas's judgment | 

## What exactly did Robert Haas say?

Haas starts from schedule. Over the past decade, he writes, PostgreSQL major releases have landed "no earlier than the middle of September, and no later than the middle of October." This year differs. Three large features, UPDATE/DELETE FOR PORTION OF, SQL Property Graph Queries (SQL/PGQ) and ALTER TABLE MERGE/SPLIT PARTITION, were reverted between August 27 and September 15. Feature freeze happens each year on April 8, and he notes that late reverts of this size are unusual.

His explanation is blunt: "What's different now is that it's become vastly easier to find those bugs. Fixing them has also gotten easier, but not to the same degree." PostgreSQL's code is large, complex and old, with a git history converted from CVS that reaches back more than 30 years, and a codebase that has always had many bugs. LLMs, he argues, changed how fast outsiders surface them.

## What do the commit numbers show?

Haas compares the same date window, April 8 to September 25, across two years.

| Metric | 2025 | 2026 | Change | 
|---|---|---|---|
| Commits to master | 1,037 | 1,443 | up about 39% | 
| Commits to the in-progress stable branch (REL_18 then REL_19) | 724 | 1,169 | up more than 60% | 
| Commits to the branch two releases back (REL_17 then REL_18) | 248 | 433 | up more than 74% | 

Note the subtlety in his own framing. The commits that landed on master only between feature freeze and September 25 "actually declined slightly" from last year, according to Haas. The growth is in back-patched commits, fixes that have to be carried into released branches. That pattern points to bug fixing rather than new feature work. One caveat: the master totals he lists (1,037 versus 1,443) rise rather than fall, which sits oddly beside that sentence, so check the git log yourself before quoting the master figure.

Two reviewers checking a code change, illustrating how LLM-found Postgres bugs add review work for committers

He also addresses the obvious alternative. "It's possible that some of this jump is the result of committers making more mistakes this year than they did last year," he writes, but he does not think anyone on the project believes that is the main cause. His reading is that committers were about as conservative as before, and "a lot more of the mistakes they made were quickly found by LLMs."

## Why would that delay a release?

Haas gives two factors. First, more bugs take more time to fix. LLMs can draft fixes, but "those fixes aren't always correct or compliant with PostgreSQL standards," so humans still have to review and commit them, and "those humans have not gotten any smarter between 2025 and 2026." Second, time that would have gone to reviewing what went into 19 was diverted into security issues and bugs in the back branches, so it took longer to decide what had to be reverted before shipping.

This is a human-bandwidth argument, not a quality collapse. Haas says plainly that the delay is not particularly concerning, since it "emerges directly from the project's concern for quality." The long-term picture is what troubles him: with forty years of bugs that humans failed to find but LLMs can, he asks how the project will "catch up" and keep innovating, and admits "right now, I'm not sure."

## What does the PostgreSQL project itself say?

The official [PostgreSQL 19 Beta 4 announcement](https://www.postgresql.org/about/news/postgresql-19-beta-4-3386/?ref=explainx), dated September 24, 2026, corroborates the reverts but frames them differently. It says the beta "reverted several features that were originally planned" and that the community "strongly believes that, first and foremost, PostgreSQL must be reliable," while also striving for "a predictable release schedule." The listed changes include:

- Revert of SQL/PGQ (property graph query) support
- Revert of online enabling and disabling of data checksums
- Revert of temporal updates and deletes via the FOR PORTION OF clause
- Revert of ALTER TABLE MERGE PARTITIONS and SPLIT PARTITIONS
- Removal of the pg_get_role_ddl(), pg_get_tablespace_ddl() and pg_get_database_ddl() functions

That notice said the release candidate was expected in early October and general availability "may also occur in October." A banner on the project's site now reads "October 15, 2026: PostgreSQL 19 RC 1 Released!" We did not find an official statement giving a general availability date or attributing any delay to AI. So the confirmed facts are the reverts, the RC, and Haas's account; the AI explanation is his as a committer, not a project position. We also did not find independent reporting that audits the commit counts, although they are verifiable in the public repository.

## How does this fit the wider AI bug-finding trend?

Haas's observation matches a pattern we have been tracking. Security-focused models and agents are now finding vulnerabilities at scale, and the burden is landing on maintainers and vendors. See [Anthropic's mission-critical infrastructure defense program](https://explainx.ai/blog/anthropic-cyber-mission-critical-infrastructure-defense-program-11-partners-2026) for how a lab is trying to channel that capability toward defenders, and [Cloudflare and OpenAI's Daybreak work](https://explainx.ai/blog/cloudflare-openai-daybreak-vulnerability-discovery-remediation-codex-1100-dollar-rebuild-2026) on discovery plus remediation. The mirror image is code that AI writes: our coverage of the [LAST secure-code benchmark](https://explainx.ai/blog/last-secure-code-benchmark-vibe-coding-agents-fable-5-25-percent-secure-2026) shows how often agent-written code is insecure, and the [Ask HN playbook on shipping AI-written code you do not understand](https://explainx.ai/blog/shipping-ai-written-code-you-dont-understand-ask-hn-meta-engineer-playbook-2026) covers the review side.

There is an upside, too. [Claude's formal verification work on 123 libraries](https://explainx.ai/blog/anthropic-claude-formal-verification-123-libraries-rocq-risc-v-proofs-2026) points at a future where models produce proofs and fixes, not just bug reports. Haas says LLM fixes still need human review, which is the bottleneck in Postgres today.

## What should builders and platform teams do?

If you run Postgres, or any widely used open-source component, the practical read is about cadence and posture rather than panic.

1. **Expect more point releases.** A 60 to 74 percent rise in back-patched commits means more minor versions and security releases. Build patching into your routine, and test upgrades on a staging replica before production.
2. **Do not treat "old and stable" as "audited."** Haas's point is that decades-old code can hide bugs that tools now find in hours. Dependencies you have trusted for years can change risk profile quickly.
3. **Plan around feature reverts.** If your roadmap assumed SQL/PGQ graph queries, online checksum toggling, or temporal FOR PORTION OF updates in 19, the Beta 4 notice says they were pulled to "be potentially included in a later major release." Do not design around them for now.
4. **If you maintain code, assume AI scrutiny.** Haas writes that "every feature that we write from now until the end of our careers will be scrutinized by AI." Invest in tests, fuzzing and review before release, because the cost of a missed bug is now a fast public report.
5. **Be a good reporter.** If you use LLMs to find bugs in open-source projects, verify them, write minimal reproductions and avoid flooding trackers; the scarce resource is maintainer attention. If you are securing your own agents that read and write code,[AgentBeam](https://agentbeam.com/?ref=explainx) , the agent security platform from the explainx.ai team, stops AI agents before they take dangerous actions.

## What are readers asking?

**Is Postgres 19 safe to adopt?** Nothing published says the release is unreliable. The project's stated reason for the reverts is to protect reliability. As with any major version, wait for the first minor releases if you run critical workloads.

**Did AI write the bad code?** Haas does not say that. He attributes the extra work to AI finding bugs in existing human-written code, not to AI-generated patches introducing them.

**Is this a Postgres-only problem?** He suggests it is not: "to some extent, every software developer on earth" will be affected. Other projects' commit and release data would be needed to test that, and we did not find a comparable published analysis.

## What remains unknown

Several things are open. We do not know the official general availability date or whether the project will formally postpone beyond November. We do not know how many of the extra back-patched commits came from LLM-assisted reports versus ordinary reports, because Haas infers the connection rather than measuring it. And we do not know whether the reverted features will return in Postgres 20. The cleanest way to check is the project's [release notes](https://www.postgresql.org/docs/19/release-19.html?ref=explainx) and the public git history for the date ranges Haas used.

The larger takeaway is the one Haas ends on: this is "both a challenge and an opportunity." Bugs that survived for decades are being found quickly, which is good for users and costly for the small group of people who must fix them.

## Related reading

- [Postgres 19 delayed: AI code review found more bugs than humans could fix](https://explainx.ai/blog/postgres-19-delayed-ai-code-review-bugs-reverted-features-2026) (our earlier report, based on The Register and Peter Eisentraut)
- [Anthropic mission-critical infrastructure defense program](https://explainx.ai/blog/anthropic-cyber-mission-critical-infrastructure-defense-program-11-partners-2026)
- [Cloudflare and OpenAI Daybreak: vulnerability discovery and remediation](https://explainx.ai/blog/cloudflare-openai-daybreak-vulnerability-discovery-remediation-codex-1100-dollar-rebuild-2026)
- [LAST secure-code benchmark: how secure is vibe-coded software?](https://explainx.ai/blog/last-secure-code-benchmark-vibe-coding-agents-fable-5-25-percent-secure-2026)
- [Shipping AI-written code you do not understand: an Ask HN playbook](https://explainx.ai/blog/shipping-ai-written-code-you-dont-understand-ask-hn-meta-engineer-playbook-2026)
- [Claude formal verification across 123 libraries](https://explainx.ai/blog/anthropic-claude-formal-verification-123-libraries-rocq-risc-v-proofs-2026)
- Official: [PostgreSQL 19 Beta 4 announcement](https://www.postgresql.org/about/news/postgresql-19-beta-4-3386/?ref=explainx) and[Haas's original post](https://neon.com/blog/postgres-19-is-late-and-its-ais-fault?ref=explainx)

*Release status and commit figures reflect the sources as of October 31, 2026 and may change.*