Postgres 19 slips to November as LLM-found bugs push back-patched commits up 74%
- PostgreSQL 19 is slipping from its usual mid-September to mid-October release window to November 2026, and Robert Haas attributes the delay to LLMs making it vastly easier to find bugs while fixing them still requires human reviewers.
- Between April 8 and September 25, back-patched commits to REL_19_STABLE rose from 724 to 1169 year over year, a jump of more than 60%, even as commits to master in the feature-freeze-to-September window declined slightly.
- Back-patching to at least one prior release grew faster: 248 commits to REL_17_STABLE in 2025 became 433 commits to REL_18_STABLE in 2026, up more than 74% in a single year.
- Three large features were reverted late in the beta period, between August 27 and September 15: UPDATE/DELETE FOR PORTION OF, SQL/PGQ, and ALTER TABLE MERGE PARTITION/SPLIT PARTITION.
- Haas says LLM-drafted fixes are often incorrect or non-compliant and still need human review, that reviewer time was diverted to back-branch security fixes instead of validating v19's contents, and that the open question is how the project ever catches up on forty years of bugs humans could not find.
Hacker News opinions
Discovery isn't the bottleneck anymore, verification is. Generating more bug reports doesn't help if the same handful of maintainers still has to validate them and review the fixes.
Probably true while dev keeps accelerating, but if the codebase is stable and features slow down, the reports should plateau eventually.
AI is great at read-only search tasks like finding bugs, not so great at write tasks like adding a feature. Search results are easy to verify, code changes are hard.
Not so sure. The most common failure in a search task is omission, and that's really hard to spot. With a feature you can just try it and see if the happy path works.
I've been coming around to that view. Everyone is focused on using AI to write code, almost nobody talks about using it to analyze code and hunt bugs.
Postgres did not have a slop problem. The delay announcement was explicit that the code was written without AI, and AI's only role was review and bug finding. Insinuating otherwise is wrong.
I found a segfault with malformed JSON in a jsonb release candidate long before AI existed, and they fixed it instead of ripping out the feature. This looks like an excuse to kill features they don't like and blame LLMs.
If you're at the release candidate stage and still uncovering segfaults, ripping the feature out is probably the only real option.
Maybe the actual problem is that so much maintainer time went to fixing discovered issues that the new features never got the same testing depth, so pulling them beat shipping them substandard.
I'm not positive on AI's impact on software generally, but this framing made me pause. If the bug reports are valid and the submitted fixes are viable, just pause feature work for a while and burn down the bug count.
Signal quality, what does that even mean? A bug can be valid and still be obscure and low priority. Not every bug needs fixing, that's a trap.
Still amazed that with all the vibe coding nobody has built a Postgres alternative.
Why would anyone? Postgres is free and does an amazing job already.
You can create a project on vibes, you cannot maintain one on vibes. Someone tried, and Jepsen analyzed ParticleDB 1.1.4.
Honestly this seems good. A slightly disrupted release cadence beats shipping bugs that haunted the codebase for a decade.
The only question is whether the delay comes from high-quality reports or from the burden of triaging garbage. The post doesn't make clear which one it is.
At work we've put a full halt on feature work because the pile of security tasks became staggering and urgent. Hopefully we get past the wave with much more secure software.
Run an LLM review against your own code before you ask a human to review it. It's common courtesy at this point.