Commenter frames delay as quality bar rising, not catastrophe
4 Nov 1 10:20 PM · 10d ago · 1 post · 4 comments · 2 sources · development 4 of 4
A Hacker News user summarized the article for readers, framing the delay as a positive outcome: the project's quality bar has risen due to more scrutiny, features are getting safer, and the codebase is hardening despite temporary disruption to release cadence.
“Postgres release is delayed due to the quality bar getting raised. New features are getting more eyeballs, and therefore leading to more rollbacks.”
flakesRobert Haas PostgreSQL major contributor, Databricks Sr. Staff Engineer
The whole story postscomments the bright band is this development · numbered dots are the others · click one to jump
What people said 24 voices · best of 71 · verbatim
-
So I read this title and thought "ah great, yet another article complaining about vibecoded features and their slop". But then I remembered reading some other article about PostgreSQL 19 in the last few weeks and how it claimed that none of its features had been written with the help of LLMs. Which made me curious to read it. The premise of the…
-
I know that it's a good thing in almost every way that these bugs are being found which used to be left undiscovered, especially security bugs, knowing that state actors probably have a significant stash of them documented and ready to use when needed.But.Something's lost in this need for perfection, knowing that every bug will be found quickly…
-
H
Postgres 19 is late because so many more bugs are being found now Link: http:// rhaas.blogspot.com/2026/10/pos tgres-19-is-late-and-its-ais-fault.html Discussion: https:// news.ycombinator.com/item?id=5 0312408
-
As much as I dislike LLMs, this seems… fine? We’re living in the age of slop where velocity is prioritized over quality. Going the other direction is good.
-
This is a good thing. Repaying technical debt is always a great thing.On our own 1.5M loc system, we've found and fixed thousands of bugs, security holes and circular dependencies in the last year. Code quality has increased, test coverage increased. We've also recently set our compiler to treat warnings as errors, and to be as strict as possible…
-
N
Postgres 19 is late because so many more bugs are being found now: http:// rhaas.blogspot.com/2026/10/pos tgres-19-is-late-and-its-ais-fault.html Discussion: http:// news.ycombinator.com/item?id=5 0312408
-
Nobody having reported a bug doesn't mean nobody is impacted. DB bugs are hard to reproduce because they're often non-deterministic, and only occur in rare conditions.
-
I sometimes think that the world would need to do a "snow leopard" release of everything... to unit test, to fix... and then we will be able to move forward... but AiMaxSlopIt will result in those situations where you have to rollback or redo from scratch parts... because it's unmantainable because it's bad... it's spread everywhere and "the map"…
-
As someone who has been loudly in favor of LLMs for quality over velocity, I've really been struggling with a lot of this. Look, a lot of the systems I help maintain are quite good, right? Not to toot my own horn too much but I've been repeatedly recognized for being able to write solid, high-quality systems. Well, I pointed LLMs at some of those…
-
> It’s possible that some of this jump is the result of committers making more mistakes this year than they did last year, but I don’t think anyone who works on the project really believes that’s the main cause. Rather, it seems likely that PostgreSQL committers were about as conservative in 2026 as they were in preceding years, but a lot more of…
-
I feel like this is _exactly_ they way it should be done.
-
> This seems…good?You would think so but medicine has faced this paradox since the development of modern testing technology.You would naively think more testing is always better. More sophisticated practitioners then talk about Type I vs Type II errors and the problem of false positives.But even if you were able to come up with tests that had 100%…
-
Exactly. It means that this iteration of Postgres was forcefully pushed into the “stabilisation” phase, which overall may be a good result for everyone, as a robust base is a better starting point for the new features. But it obviously frustrates some developers who can not push new stuff as fast as they wanted.
-
AI makes it possible to fix bugs and solves issue one wouldn't do before. But just because it's easier now doesn't mean it's automatically worth it. There are tradeoffs (like code complexity or breaking stuff), or it really just wasn't that important to fix if it was in the backlog forever. I've seen devs go down this rabbit hole, and perhaps…
-
It is; certainly if it produces observable behaviour that was unintended but people now rely on (Hyrum’s law), and is now blocking features or performance patches, for example.
-
Ok, but does (s)he know? It's just guessing, so unfounded non-news?"It’s possible that some of this jump is the result of committers making more mistakes this year than they did last year, but I don’t think anyone who works on the project really believes that’s the main cause. Rather, it seems likely that PostgreSQL committers were about as…
-
I am wondering: if we leave security bugs out of the picture, is a bug really a bug if no-one was impacted by it over a long enough time and a wide enough install base?
-
Like the warnings as errors, and extensive test suites, there's also type safety that helps stir the LLM in the right direction.You can go with "eliminate all 3rd party dependencies [...] frontends completely using zero frameworks" and be stuck with JS. Or use a typed language (TS, ReasonML/ReScript or even Elm) and an API client generator…
-
Indeed. I would also prefer more bugfixes in pgsql 19 than new features. IMO this is a golden oppurtunity to postpone new features to version 20.
-
> rebuild our frontends completely using zero frameworks, not touching npm ever again after thatGenuine question, because I don’t know: Wouldn’t it suffice to vendor your current packages and “only” stick to maintenance from there on out, instead of rewriting it all?This should still achieve the goal of not needing to touch npm, but presumably…
-
I think in the author's eyes that more bugs were found is also a good thing: > In the end, I don’t think that the delay in shipping PostgreSQL 19 is particularly concerning. It is not a long delay in the grand scheme of things, and it emerges directly from the project’s concern for quality. Nonetheless, I think he might also be concerned about the…
-
Not specific re Postgres, just a general observation:A pattern I'm seeing w/ companies and projects not used to continuous delivery (or at least shorter release cycles) is that they are slipping in schedules more now.I think in the current environment it makes a lot of sense to re-think how often releases get cut and how to handle security related…
-
I have mixed feelings about this post and the reactions to it. Over the years I have evolved from "oo, shiney Nosql, that looks new" to "just use Postgres, it's the standard and its solid". That postgres basically gobbles most new db paradigms, rendering all but the most niche-needy adopters with no choice but to stick with postgres, speaks of a…
-
Good thing if you can afford the vulnerability detection run.I could imagine scenarios where only well off developers and companies could afford that.Then if you don't have the money, you are out of luck and risk having vulnerabilities in your code.And it takes just one adversary to pay the bot & the bot will happily find an exploit for them in…
All 4 developments of PostgreSQL 19 delayed to November as LLM-found bugs… →
Hacker NewsNewswiresMastodonLobsters