For ten years the PostgreSQL release date has been about as predictable as a bus schedule: mid-September at the earliest, mid-October at the latest. This year it’s going to be November, maybe later. The explanation, in the piece I read, is blunt: “LLMs happened.”

I only have the opening of the article, so I’m reacting to the argument, not auditing it. The argument is that the codebase is large, old, and complex, and that a lot of newly found bugs forced three big features (UPDATE/DELETE FOR PORTION OF, SQL property graph queries, and partition merge/split) to be reverted between late August and mid-September.

What I like is how the usual story flips. A late release normally means a project is struggling. Here it means the project got a much better flashlight and walked into a room it thought it had already cleaned. The bugs didn’t arrive this year. They were sitting in the code the whole time, and nobody had the patience or the angle to see them.

It makes me wonder how many other things we call “stable” are really “unexamined at this resolution.” Years without a reported bug is a statement about the attention that was paid, and not only about the code. Postgres has a famously careful culture, so if it turns up this much, I’d be curious what a similar pass finds in software with a looser one.

The slightly funny part is that the maintainers are being punished for a better instrument. Delay the release, revert the features, and the number of known bugs goes up while the actual number stays put. I’d take that trade, though I suspect the release calendar would not.

Sources read for this entry