PostgreSQL 19 delay: how a bug found with AI turns into back-patches, less review time and late reverts
|

The PostgreSQL 19 delay: AI is one factor, according to two committers

ByHécate Regnier Databases, Sysadmin notebook

The PostgreSQL 19 delay explained: what Robert Haas and Peter Eisentraut say about AI-found bugs, my own commit counts and what DBAs can do.

The PostgreSQL 19 delay has a stated cause in two posts by PostgreSQL committers: bugs found with the help of AI. Robert Haas published his post on the Neon blog on October 21, 2026 and on his own blog on October 30, 2026. Peter Eisentraut published his post on October 9, 2026. Their emphasis differs, so this article keeps their voices apart.

What Haas says about the PostgreSQL 19 delay

Haas writes that major releases of the past decade landed between mid-September and mid-October. This year, he says, PostgreSQL 19 will most likely ship in November, and a further postponement is not impossible. He also notes that three large features left the release between August 27 and September 15: UPDATE/DELETE FOR PORTION OF, SQL property graph queries (SQL/PGQ) and ALTER TABLE … MERGE/SPLIT PARTITION. Feature freeze, he adds, falls on April 8 every year.

His explanation is volume. According to the post, LLMs made old bugs much easier to find, while fixing them got easier only to a smaller degree. Many people now report bugs they found with LLMs, and committers have been busy fixing them. He does not blame more committer mistakes, because he thinks that is unlikely to be the main cause. Instead, he thinks committers stayed as careful as before and LLMs caught more of their mistakes quickly.

He then gives two reasons for the late reverts. First, LLMs can draft fixes, but those fixes are not always correct, so humans still review and commit them. Second, time that would have gone to reviewing the release went to security issues and bugs in the older branches. In his view the delay is not particularly concerning. However, he calls the long-term picture less clear: how will the project catch up on decades of bugs and keep innovating? He writes that he is not sure yet.

PostgreSQL 19 delay: how a bug found with AI turns into back-patches, less review time and late reverts
As the post describes it: a qualitative flow, with no figures.

What Haas does not claim

  • He does not claim that LLM-written fixes are reliable.
  • He does not give a firm release date, and he does not count how many bugs LLMs found in total.
  • He does not explain why each of the three features was reverted.
  • He still rates the PostgreSQL code base as very high quality.

What Eisentraut says about the reverts

Eisentraut wrote earlier and gives a wider picture. He says about 8 to 10 significant features, depending on how you count, left the PostgreSQL 19 branch after the beta period began, and he was the developer or committer of some of them. He calls his post a set of personal opinions and says the causes are probably a combination that differs for each feature.

  • Code quality: maybe the code was not good enough, and he says the team will learn from it.
  • Features too hard to finish: some had architectural defects that were hard to fix during beta.
  • A long tail of edge-case bugs: LLM-assisted code review now finds these much faster, and he gives the example of staring at “like forty defect reports”. That sentence illustrates the point. It is not measured data.
  • Less review: senior developers spent April to August on security fixes, so the usual beta review shrank.
  • Complexity: in PostgreSQL “everything works with everything”, which makes some features very hard to get right.
  • No experimental status: the community has discussed it, but it has no way to do it yet.

Importantly, he says the situation is not due to “vibe coding”, because the reverted code is older than that. In his reading, AI review raised the quality bar after the code had been written. He adds that this should sort itself out in future cycles unless LLM review keeps improving at the current rate. He also says the community preferred to keep the release schedule rather than delay. He expects many reverted features to return before long. Finally, he names REPACK CONCURRENTLY, logical replication of sequences and pg_plan_advice among the headline items, and he mentions a few features that are about 80 percent ready for PostgreSQL 20.

What the project itself published

Most importantly for the PostgreSQL 19 delay, the release candidate announcement of October 15, 2026 gives a schedule. The next scheduled update release, on November 12, will include a large number of fixes, so the release team decided to include them in PostgreSQL 19 before general availability. Therefore the team plans a second release candidate on November 12, and it plans general availability on November 19, 2026, unless an issue requires a delay or another candidate. As of November 5, 2026, these dates are plans.

PostgreSQL 19 delay: calendar from the April 8 feature freeze to the planned release of November 19
Only dates stated by the post or by postgresql.org in early November 2026.

My take

On the PostgreSQL 19 delay, I am less worried than the headlines. Fixing many bugs and vulnerabilities is rather a good thing, even when it costs time. If the base becomes much more stable, I think the race to innovate can wait a little. This is my reading, not a measurement: nothing I counted shows whether the base is more stable today.

Haas himself calls the delay modest and still rates the code very highly. However, he also says the long-term question is open: how can the project catch up on its backlog and still innovate? He also calls the code base some of the cleanest he has worked on, and Eisentraut, for his part, expects many reverted features to return before long. So my view and the posts fit together, but the optimism is mine, not theirs. If you run PostgreSQL more than you follow its development, how it stores tables and indexes in files on disk is the second part of my data files series.

Related articles

Sources

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *