Postgres 19 is late, and it's AI's fault

Friday, October 30, 2026 Postgres 19 is late, and it’s AI’s fault Over the past decade, the timing of PostgreSQL major releases has become very predictable: no earlier than the middle of September, and no later than the middle of October. This year is going to be different. PostgreSQL 19 most likely won’t be released until November, and it’s not impossible that the project could decide to postpone the release further.

2026年10月30日，星期五。Postgres 19 延期了，这得怪 AI。在过去十年里，PostgreSQL 主要版本的发布时间变得非常可预测：不早于 9 月中旬，不晚于 10 月中旬。但今年情况有所不同。PostgreSQL 19 很可能要到 11 月才会发布，而且项目组甚至有可能决定进一步推迟发布。

Moreover, this year, several rather large features were reverted quite late in the beta period: UPDATE/DELETE FOR PORTION OF, SQL Property Graph Queries (SQL/PGQ), and ALTER TABLE … MERGE PARTITION/SPLIT PARTITION were all reverted between August 27 and September 15. While major feature reverts are not especially uncommon immediately after feature freeze, which each year occurs on April 8, it is unusual to see multiple major features get pulled from the release at such a late date. So, what happened?

此外，今年有几个相当大的功能在测试阶段后期被撤回：UPDATE/DELETE FOR PORTION OF、SQL 属性图查询 (SQL/PGQ) 以及 ALTER TABLE … MERGE PARTITION/SPLIT PARTITION 均在 8 月 27 日至 9 月 15 日期间被撤回。虽然在每年 4 月 8 日的功能冻结后立即撤回主要功能并不罕见，但在如此晚的日期撤回多个主要功能是不寻常的。那么，到底发生了什么？

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.

简短的回答是：大语言模型（LLM）出现了。所有软件都包含漏洞，而 PostgreSQL 的代码库庞大、复杂且历史悠久。我们的 git 历史记录（从 CVS 转换而来）现在可以追溯到 30 多年前，而最初的代码编写时间还要早十年。代码量巨大，其中包含的漏洞也数不胜数。这种情况一直存在，但这并没有阻止 PostgreSQL 变得流行和成功。现在的不同之处在于，发现这些漏洞变得容易多了。修复它们也变得更容易了，但程度不及发现漏洞那么显著。

Between April 8th, 2025 and September 25, 2025, there were 1037 commits to PostgreSQL’s master branch and 724 commits to REL_18_STABLE. In 2026, during the same date range, there were 1443 commits to the master branch and 1169 commits to REL_19_STABLE. In other words, if you look at the number of commits that went into the master branch only between feature freeze and September 25th, it actually declined slightly from last year to this year, but the number of back-patched commits jumped by more than 60%.

在 2025 年 4 月 8 日至 2025 年 9 月 25 日期间，PostgreSQL 主分支有 1037 次提交，REL_18_STABLE 分支有 724 次提交。2026 年同期，主分支有 1443 次提交，REL_19_STABLE 分支有 1169 次提交。换句话说，如果只看功能冻结到 9 月 25 日之间进入主分支的提交数量，今年实际上比去年略有下降，但向后移植（back-patched）的提交数量却跃升了超过 60%。

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 the mistakes they made were quickly found by LLMs.

这种增长的部分原因可能是提交者今年犯的错误比去年多，但我认为项目组中没有人真正相信这是主要原因。相反，更有可能的是，PostgreSQL 提交者在 2026 年的表现与往年一样保守，但他们所犯的错误中有更多被 LLM 迅速发现了。

And it isn’t just mistakes in the latest release. In the same time period, during 2025, there were 248 commits to REL_17_STABLE, and during 2026, there were 433 commits to REL_18_STABLE. In other words, the number of commits being back-patched not just to the release in progress but also to at least one prior release jumped by more than 74% in a single year. The reason for this is simply that a huge number of people on the Internet are now reporting bugs in PostgreSQL that they found using LLMs, and the PostgreSQL committers have been very, very busy fixing them.

这不仅仅是最新版本中的错误。在 2025 年同期，REL_17_STABLE 有 248 次提交，而 2026 年 REL_18_STABLE 有 433 次提交。换句话说，不仅针对正在进行的版本，而且针对至少一个先前版本的向后移植提交数量在一年内跃升了超过 74%。原因很简单：互联网上有大量的人现在正在使用 LLM 发现 PostgreSQL 中的漏洞并进行报告，而 PostgreSQL 的提交者们一直在非常、非常忙碌地修复这些漏洞。

And I think that’s also why we had so many late reverts, and why the release itself is delayed. Two factors are at play here. First, because so many more bugs are being found now, it takes more time to fix them. LLMs can draft fixes, but those fixes aren’t always correct or compliant with PostgreSQL standards. So, they still need to be reviewed and committed by humans, and those humans have not gotten any smarter between 2025 and 2026.

我认为这也是我们出现如此多后期撤回以及发布本身延期的原因。这里有两个因素在起作用。首先，由于现在发现的漏洞多得多，修复它们需要更多时间。LLM 可以起草修复方案，但这些方案并不总是正确或符合 PostgreSQL 标准的。因此，它们仍然需要由人类进行审查和提交，而这些人类在 2025 年到 2026 年之间并没有变得更聪明。

Second, time that would have been spent reviewing what went into the release got diverted into addressing security issues and other bugs in the back-branches, and so it took longer to figure out what needed to be reverted before shipping v19.

其次，原本用于审查发布内容的时间被转移到了处理安全问题和旧分支中的其他漏洞上，因此在发布 v19 之前，确定需要撤回哪些内容花费了更长的时间。

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.

最后，我认为 PostgreSQL 19 的发布延迟并不特别令人担忧。从大局来看，这并不是很长的延迟，而且它直接源于项目组对质量的关注。

The long-term picture is less clear and in some ways more troubling: given that we have forty years of bugs that humans were unable to find but LLMs are quite capable of discovering, how are we ever going to catch up, and how will PostgreSQL continue to innovate? Right now, I’m not sure. What I do know is that I, and many others, are working really hard to figure it out.

长期前景尚不明确，在某些方面更令人不安：鉴于我们有四十年的漏洞是人类无法发现但 LLM 却完全有能力发现的，我们该如何赶上？PostgreSQL 又将如何继续创新？目前，我还不确定。我所知道的是，我和许多其他人正在非常努力地寻找答案。

I became a PostgreSQL developer partly because the PostgreSQL code base is some of the cleanest and highest-quality code upon which I have ever had the privilege to work. The recent success of AI in finding bugs in that code base does not change my high estimation of it. It is not perfect – no software product is – but if it had more defects visible even to human eyes, the number of things found by LLMs would likely be even greater.

我成为 PostgreSQL 开发人员的部分原因在于，PostgreSQL 代码库是我有幸工作过的最干净、质量最高的代码之一。最近 AI 在该代码库中发现漏洞的成功并没有改变我对它的高度评价。它并不完美——没有软件产品是完美的——但如果它有更多肉眼可见的缺陷，那么 LLM 发现的问题数量可能会更多。

There’s no escaping the fact that LLMs are going to require every PostgreSQL developer – and some extent, every software developer on earth – to raise their game. Every feature that we write from now until the end of our careers will be scrutinized by AI, and things that would have escaped forever unnoticed in an earlier era will now be found, perhaps in a matter of hours. That’s both a challenge and an opportunity.

不可否认的事实是，LLM 将要求每一位 PostgreSQL 开发人员——在某种程度上，地球上的每一位软件开发人员——提升他们的水平。从现在到我们职业生涯结束，我们编写的每一个功能都将受到 AI 的审查，而在过去时代永远不会被注意到的问题，现在可能会在几小时内被发现。这既是挑战，也是机遇。