--- title: Postgres 19 delayed after AI reviewers find more bugs... description: PostgreSQL 19 has been delayed from late September/early October to around November 19, with eight to ten significant features pulled and pushed to PostgreSQL... canonical: https://daily.dev/posts/postgres-19-delayed-after-ai-reviewers-find-more-bugs-than-humans-can-fix-tzu3o3qdp twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Postgres 19 delayed after AI reviewers find more bugs than humans can fix | daily.dev og:description: PostgreSQL 19 has been delayed from late September/early October to around November 19, with eight to ten significant features pulled and pushed to PostgreSQL... og:url: https://daily.dev/posts/postgres-19-delayed-after-ai-reviewers-find-more-bugs-than-humans-can-fix-tzu3o3qdp og:image: https://api.daily.dev/og/posts/Tzu3o3qDP.png og:image:alt: Postgres 19 delayed after AI reviewers find more bugs than humans can fix og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Postgres 19 delayed after AI reviewers find more bugs than humans can fix **[Hacker News](https://daily.dev/sources/hn)** · 4 min read · 0 upvotes · 0 comments ## Summary PostgreSQL 19 has been delayed from late September/early October to around November 19, with eight to ten significant features pulled and pushed to PostgreSQL 20. EDB's Peter Eisentraut attributes much of the delay to LLM-assisted code review, which surfaced a long tail of edge-case bugs that would previously have surfaced only after release. He stresses the reverts aren't due to vibe coding, since that technique wasn't used when most of the features were written. One dropped feature is SQL Property Graph Queries (SQL/PGQ), pulled over unresolved issues after contributor Tom Lane warned it would ship with unfixable bugs. REPACK CONCURRENTLY, which avoids table-lock VACUUM FULL, remains in the release. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### why was PostgreSQL 19 delayed PostgreSQL 19 was delayed from a late September/early October target to around November 19 because LLM-assisted code review uncovered far more edge-case bugs than developers could fix in time. Eight to ten significant features, including SQL Property Graph Queries, were reverted and pushed to PostgreSQL 20, which will now include new features rather than being a bug-fix-only release. _Tracking how database releases slip reflects daily.dev's beat on real-world PostgreSQL upgrade timing and risk._ ### is PostgreSQL 19 delay caused by vibe coding No, PostgreSQL committer Peter Eisentraut explicitly said the reverts in PostgreSQL 19 were not caused by vibe coding, since that technique was not available when most of the affected features were originally written. Instead, the issue stems from LLM-assisted code review becoming more effective over time, raising the quality bar after the code had already been committed. _Developers weighing AI's real impact on codebases can follow stories like this on daily.dev before drawing conclusions._ ### what happened to SQL Property Graph Queries in PostgreSQL 19 SQL/PGQ, the SQL standard syntax added in 2023 for exploring node-and-edge relationships, was removed from PostgreSQL 19 over unresolved implementation issues. Contributor Tom Lane had warned beforehand that shipping it in v19 risked post-release bugs unfixable until v20, and the feature is now expected to land in PostgreSQL 20 instead. _Teams planning around graph query support in PostgreSQL can watch this rollout unfold on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 1 discussion and 38 comments across hackernews (as of 2026-10-16). **TL;DR:** Discussion centers on whether LLM-assisted review is genuinely surfacing more real bugs or just creating a new flood of noisy, hard-to-triage findings, with many skeptical of relying on AI-generated bug reports without human verification. **Sentiment:** 15% positive · 35% mixed · 50% skeptical **The case for** - Using AI specifically to find bugs rather than write code is seen as a genuinely good use case. - Some find that dedicated review-loop models catch subtle design-intent issues that are valuable even if costly to fix. - A few see this as evidence of AI raising the overall quality bar across long-standing codebases. **The pushback** - Several warn that AI bug reports are often noisy, exaggerated, or outright fabricated and need human triage before being trusted. - Some describe a doom loop where fixing AI-found bugs with AI-generated code introduces new bugs, repeating endlessly. - Commenters note AI-authored fixes are often overengineered, bloated, or add excessive/unnecessary tests. - Skepticism toward EDB's framing given the company's commercial interest in promoting AI tooling. - Doubt about whether this represents more bugs overall versus simply earlier detection of bugs that always existed. **By community** - hackernews (mixed): Opinions split between enthusiasm for AI-assisted review catching real issues and heavy skepticism about noisy, unreliable, or self-serving AI bug reports. **Hottest debate:** Whether the surge in reported bugs reflects a genuine new problem introduced by AI-era development or simply AI tooling finally surfacing long-dormant defects that always existed in the codebase. **Open questions** - Are the newly found bugs actually valid, or does the triage burden of verifying AI-generated reports offset the benefit of finding them? - Will this pattern of AI-driven review slow down release cadences industry-wide, and is that a net productivity loss or gain? **Highlights** > I tried that this summer. I encountered this doom loop where the review agent would find bugs, the coding agent would fix them in some overengineered way that introduced new bugs, the review agent found them, the coding agent made more while fixing them, repeat until insanity. Not every time. But often enough. > — [bunderbunder on hackernews · 3 comments](https://news.ycombinator.com/item?id=50121714) > Seeing how Fable handled Linux kernel bugs, where out of 82 bugs reported only 6-8 were actually bugs (not already fixed or fixed in newest version or straight up made up) I'm skeptical till humans actually sift through this pile. > — [Ygg2 on hackernews](https://news.ycombinator.com/item?id=50122015) > If its more "bugs than humans can fix", its also likely "more bugs than humans can triage and verify as legitimate bugs". Sorry, garbage in garbage out doesnt fly. I feel sad for open source maintainers having to deal with this massive slop-ageddon. > — [BatchJob on hackernews · 1 comments](https://news.ycombinator.com/item?id=50121679) > QA is becoming the blocker for projects in an AI era, and the real source of value. AIs can lay down a good base of testing but I see even frontier models still need help with testing because they are basically as bad as humans in terms of testing only what comes to mind, if not even a touch worse. Though they are really good at blasting through problems once they are found. Ironically, despite the predictions that AI will murder SaaS, I think the result is they end up even more entrenched, because Job Bob's Bait Shack And Tax Filing Services may be happy to instantiate some front office system for themselves via AI prompt, but they aren't going to want to QA that post-AI any more than they want to now. Once we all settle down, SaaS will manage more code than before, and do more QA, and Joe Bob's etc. will be even less interested in trying to replicate the work with AI because it will represent an even larger QA load than it does today, relative to the size of their business. Or, to put it in the context of this article, even if you can prompt a database into being today, which you can, you can't prompt something into existence that has been tested and QA'd like Postgres, and you would be well advised to ponder that gap between your prompt and billions of computer hours of field testing very carefully before you decide where to store your company's most important data. > — [jerf on hackernews · 2 comments](https://news.ycombinator.com/item?id=50122258) > Some conjecture on my part, but I imagine that the bugs being found are not the kind you can just press a button on the LLM to fix anyway, but are instead the sort of bugs which require the reviewer to deeply consider design tradeoffs, of which I believe there are simply more in a DB or programming language codebase, for example. Stuff I am finding in review is often like "this thing isn't like the other thing, which has this behavior, which is wrong if the aim is X, but sort of correct if the aim is Y, and totally perfect is the goal is Z and the use case is J, but not I. Unless it's Q, in which case you probably need to reconsider some fundamental decision making from 12 months ago and have some conversations with people about how users desire it to work in the first place, and then set about understanding the tradeoffs inherent to that design." > — [devin on hackernews · 2 comments](https://news.ycombinator.com/item?id=50121466) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=50119991) · 117 points · 38 comments ## Similar posts on daily.dev - [PostgreSQL 19 Beta Introduces SQL Graph Queries and Concurrent Table Repacking](https://daily.dev/posts/postgresql-19-beta-introduces-sql-graph-queries-and-concurrent-table-repacking-2adopzbmz) · InfoQ · 91 upvotes · 4 comments --- Tags: [#open-source](https://daily.dev/tags/open-source), [#postgresql](https://daily.dev/tags/postgresql), [#ai-coding](https://daily.dev/tags/ai-coding), [#code-review](https://daily.dev/tags/code-review) [View this post on daily.dev](https://daily.dev/posts/postgres-19-delayed-after-ai-reviewers-find-more-bugs-than-humans-can-fix-tzu3o3qdp) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Postgres 19 delayed after AI reviewers find more bugs than humans can fix","url":"https://daily.dev/posts/postgres-19-delayed-after-ai-reviewers-find-more-bugs-than-humans-can-fix-tzu3o3qdp","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/postgres-19-delayed-after-ai-reviewers-find-more-bugs-than-humans-can-fix-tzu3o3qdp"},"datePublished":"2026-10-16T17:18:59.810Z","dateModified":"2026-10-16T19:01:23.738Z","description":"PostgreSQL 19 has been delayed from late September/early October to around November 19, with eight to ten significant features pulled and pushed to PostgreSQL...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/0c469305e3e58c26eade43d7f3d15d8e?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/0c469305e3e58c26eade43d7f3d15d8e?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/postgres-19-delayed-after-ai-reviewers-find-more-bugs-than-humans-can-fix-tzu3o3qdp","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"open-source,postgresql,ai-coding,code-review","timeRequired":"PT4M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"Postgres 19 delayed after AI reviewers find more bugs than humans can fix"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/postgres-19-delayed-after-ai-reviewers-find-more-bugs-than-humans-can-fix-tzu3o3qdp#faq","mainEntity":[{"@type":"Question","name":"why was PostgreSQL 19 delayed","acceptedAnswer":{"@type":"Answer","text":"PostgreSQL 19 was delayed from a late September/early October target to around November 19 because LLM-assisted code review uncovered far more edge-case bugs than developers could fix in time. Eight to ten significant features, including SQL Property Graph Queries, were reverted and pushed to PostgreSQL 20, which will now include new features rather than being a bug-fix-only release. Tracking how database releases slip reflects daily.dev's beat on real-world PostgreSQL upgrade timing and risk."}},{"@type":"Question","name":"is PostgreSQL 19 delay caused by vibe coding","acceptedAnswer":{"@type":"Answer","text":"No, PostgreSQL committer Peter Eisentraut explicitly said the reverts in PostgreSQL 19 were not caused by vibe coding, since that technique was not available when most of the affected features were originally written. Instead, the issue stems from LLM-assisted code review becoming more effective over time, raising the quality bar after the code had already been committed. Developers weighing AI's real impact on codebases can follow stories like this on daily.dev before drawing conclusions."}},{"@type":"Question","name":"what happened to SQL Property Graph Queries in PostgreSQL 19","acceptedAnswer":{"@type":"Answer","text":"SQL/PGQ, the SQL standard syntax added in 2023 for exploring node-and-edge relationships, was removed from PostgreSQL 19 over unresolved implementation issues. Contributor Tom Lane had warned beforehand that shipping it in v19 risked post-release bugs unfixable until v20, and the feature is now expected to land in PostgreSQL 20 instead. Teams planning around graph query support in PostgreSQL can watch this rollout unfold on daily.dev."}}]} ```