Postgres 19 is late because so many more bugs are being found now

Posted by soheilpro 2 days ago

Postgres 19 is late because so many more bugs are being found now(rhaas.blogspot.com)

523 points | 325 commentspage 5

PIYUSHMSONI98 5 hours ago|

[flagged]

wiseowise 4 hours ago||

> The short answer is that LLMs happened. All software contains bugs, and PostgreSQL’s code base is large, complex, and old. Our git history – converted from CVS – now reaches back more than 30 years, and the first code was written a decade before that. There’s a huge amount of code, and that code contains a huge number of bugs. That’s always been true, and it hasn’t stopped PostgreSQL from being popular or successful. 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.

LLMs are a gimmick, btw. This is an Anthropic marketing stunt, how much did they pay you? /s

minfazhai 9 hours ago||

[flagged]

Anilrana921192 4 hours ago||

[dead]

bosshawg 6 hours ago||

TLDR After decades of being increasingly whittled down and optimized, an absoltuely fundamental piece of computing is now predomaitnely fixing bugs rather than adding new features.

nimchimpsky 10 hours ago||

[dead]

ltbarcly3 11 hours ago||

I have found major bugs in late beta's of postgres long before AI came along. I found a bug where malformed json would segfault the entire server (a segfault in a server process forces the entire cluster to shut down by design) when using jsonb in a release candidate once. They fixed it rather than ripping the entire feature out.

https://www.postgresql.org/message-id/20140818195634.2543.56...

It seems quite possible that someone wants to make it seem like LLMs are causing problems by over-reacting to things that could just be fixed, or delay the release slightly (or maybe waiting until late before a release to kill features they don't like?) Whatever it is, this seems like a dysfunctional process.

benjiro29 11 hours ago||

Maybe its more a issue that X amount of people have more work to fix discovered issues. So the new features have not undergone the same level of testing as before.

And instead of releasing substandard new features, they rather focus on getting rid of the backlog and have more time to test.

LLMs are in effect directly responsible for this (in a positive way by finding a ton of issues that can be security issues). Reality is with LLMs now in the world, more work needs to be done on existing software as their ability to find bugs/security weaknesses is strong.

When the old bugs/security weaknesses are fixed, things will go back to a more normal release schedule.

ltbarcly3 11 hours ago||

Are the features bad by design? Like are they bad even if they work perfectly because they add bad abstractions to pg's SQL syntax, or are just broken in how they are supposed to work? If so the process is dysfunctional to let them get this far before noticing.

Are the features designed well (from a product perspective) but implemented poorly? Again, the process is dysfunctional to let them get this far before it notices.

Were there known issues with these that were planned to be fix, but the fixes didn't happen in time? That would make sense and it happens, but how is an LLM making that worse? LLMs in the worst case let you get the same work done more quickly, because you can always get the work done as quickly as you ever could by just not using an LLM. So the strongest thing you might say here is that you thought LLMs would let you get a feature into shape before it was too late, and for whatever reason that was overly optimistic.

StilesCrisis 11 hours ago||

If you are at the RC stage and still uncovering segfaults, "rip the feature out" is probably the only choice.

meow9 11 hours ago||

I’m still amazed that with all the vibe coding, no one has created a Postgres alternative

TomatoCo 11 hours ago||

Someone tried. https://jepsen.io/analyses/particledb-1.1.4

nfriedly 11 hours ago|||

Why would they? Postgres is free and does an amazing job.

j16sdiz 2 hours ago|||

I don't know, but there are tons of "rust rewrite" of everything.

sapphire4 10 hours ago||||

I wish they'd adopt, merge in, or give official blessings to versioned postgres extensions like citus and pgvector.

nimchimpsky 10 hours ago||

why ? Just install the extension and use it

isbvhodnvemrwvn 5 hours ago||

Lack of the extension in the core means that a lot of vendors with managed postgres don't support it or ship very old versions.

spolitry 11 hours ago||||

Also Postgres has enjoyed decades of debugging.

scrollaway 11 hours ago|||

To be honest I would love for someone to work on the structuring of pg_dump for example, which is entirely driven by regexes and binary structures. It’s awful and absolutely not programmable - a real shame.

esalman 11 hours ago|||

You can create a project on vibes, but you cannot maintain one on vibes.

sa46 11 hours ago||

Many recent relational databases speak the Postgres wire protocol. For wholesale replacement, pgrust is a recent, contentious contender.

gnabgib 11 hours ago||

I hope you don't believe this, PGRust has fallen far from grace. Wire protocol support is useful (other than said recommendation)

Remove pgrust: the entry is cheating (per-query kernels and result caching) (197 points, 10 days ago, 166 comments) https://news.ycombinator.com/item?id=50205816

malisper 10 hours ago||

I work on pgrust. We shouldn't have submitted the preview when we did: it was still in active development, and its SQL coverage was far too narrow, though there was nothing in it giving it an unfair performance advantage

For the other two claims in the removal PR, we wrote scripts you can use to verify the behavior of the original 0.4-preview binary:

  - Per-query kernels did not serve the benchmark queries[0]
  - The preview's fast repeat LIKE queries came from a dictionary filter cache, not a cached query result[1]

Our open-sourced 0.4-beta has now been merged and is back on ClickBench[2][3]

Across all queries and instance sizes on ClickBench, 0.4-beta is ~7% faster overall than the 0.4-preview binary that was removed. If 0.4-preview's numbers had come from hardcoded kernels or faked results, the open-source general engine wouldn't be beating it

[0] https://pgrust.com/downloads/archive/2026-09-clickbench-snap...

[1] https://pgrust.com/downloads/archive/2026-09-clickbench-snap...

[2] https://benchmark.clickhouse.com/

[3] https://github.com/ClickHouse/ClickBench/pull/2751

nektro 10 hours ago||

postgres is mature database used the world over allegedly about to be on major version 19. how has the time not been spent already to get rid of the bugs?

Sharlin 10 hours ago|

...are you serious?!

xlayn 8 hours ago|

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" is not there.

Anecdote, I did a travel across USA and when I was looking for a hotel, if you go from apple maps, to website, to try to book, the "load browser" in the maps... could end in states where you could not go back because back is get out of where you are and go back to the start of the map... and was a terrible experience... then you turbo charge it with "implement game changer UI improvements for the new bar on UI design" goal of some guy with enough power to make damage... and you end with softslop (or is it sloprosoft?)