PostgreSQL 19 is late. The release team pushed GA to November 19 and added a second release candidate, because the back branches had collected more fixes than one release could carry. The team calls the cycle atypical, and Vondra notes it comes after years of hitting the date. Something changed, and the popular explanation is that AI found bugs so deep that features had to be pulled at the last minute.
I read the sources behind that explanation. The features were not pulled because the bugs were deep. My reading is that the patches went unread until the last minute, and that the reason is structural. The same handful of senior people triages security reports and does post-commit review, and the security reports multiplied.
The dates below are facts; the reading above is mine.
What the record says
On August 13, PostgreSQL 18.6 went out with 28 CVEs in a single minor update. That release was also the beta release for 19, which is a strange pairing on its own: 28 security fixes and a beta, side by side.
On August 25, Robert Haas asked Claude to rank the scariest v19 patches by the number and type of bugs fixed after feature freeze. Six made the list. He had no position and asked whether any were in bad enough shape to revert.
In September, four of the six were reverted. SQL/PGQ on the 7th. The RI fast-path batching on the 10th. UPDATE/DELETE FOR PORTION OF on the 15th. Online data checksums on the 16th. Haas did not demand the reverts. He asked whether they should be discussed.
On October 1, Tomas Vondra went through the reverts himself. He counted 12 major ones. His verdict on the cause is deflating. Most came out of ordinary human review, and only a few trace to AI. The viral story does not match the threads.
Then the part I think matters. Vondra plotted reverts per development day back to Postgres 14. By number, PG19 is about on track. It has more commits than PG14, so the fraction reverted is lower. The unusual thing is when they land. Earlier cycles cluster right after feature freeze, around day 300. PG19 has nothing there. The line goes flat, then spikes around day 430, in early September. Review went missing in that stretch. It came back later, late and all at once.
On October 9, Peter Eisentraut wrote from the receiving end. He counts 8 to 10 significant features reverted, depending how you count. He lists causes that are mostly human: architectural defects, a long tail of edge cases that LLM-assisted review finds faster than anyone can work through, and senior developers tied up on security fixes from April to August. He says the usual beta review was reduced, then picked up again in August. That is his guess at why so much surfaced so late. It is a good one.
On October 10, the release team moved GA to November 19, kept RC1 on October 15, and scheduled an RC2 for November 12 so the back-branch fixes could ship ahead of the major release.
The project’s security page is the number that holds it together. It lists 44 CVEs with 2026 identifiers. For 2023, 2024, and 2025 it lists 7 each. Same page, same project, same counting.
The same people
Here is the mechanism, and it is a position, not a measurement. Security triage and post-commit review draw on the same people. Vondra says a significant number of senior contributors spent the year handling security reports, some of which came from AI. Eisentraut calls the stretch the Vulnpocalypse and says the beta review thinned because of it. Two people in the middle of the cycle describe the same squeeze.
If that is right, the interesting quantity is not how many bugs AI can find. It is how many hours are available to read a patch. A 28-CVE update is not one event. Each report needs a reproducer, a fix, a review, and a back-branch decision, and each one lands on the desk of someone who would otherwise be reading new SQL. In that comparison, I think security gets those hours by default. A security report usually has a deadline. A patch does not. It just sits.
The asymmetry
There is a second reason generated work is expensive, and it has nothing to do with average quality. You can ignore a patch. Nothing happens to you. A review is different. The expectation on the mailing list, as I read it, is that every point gets an answer, so a review with six findings, four of them noise, can mean six replies from the author. Producing findings is cheap. Answering them is not. The cost lands on the person who was already the bottleneck, which is the worst place to put it.
I would rather see fewer reviews that are better. I do not think that happens by asking nicely.
Three rules I want
Disclose the tool. If a model helped write what you post, say so in the message. Not in a footnote, not three replies later. A reviewer deciding how far to trust a claim needs to know where the claim came from, and the same goes for a patch.
Own every point. If you post a finding, it is yours. “The model suggested it” is not an answer when someone asks about it. If you cannot defend a point, do not send it. This is the rule that kills the six-finding review, because generating findings is free and defending them is not.
Hold reviews to a stricter rule than patches. A patch is a proposal and may be wrong. A review is an assertion about someone else’s work, and asserting should cost more than proposing. Today it costs less.
As far as I can tell, the project still has no official AI contribution policy. When it writes one, I hope it starts from the queue instead of the tool. The queue is the scarce resource. Multiplying what arrives at it does not make anything cheaper. It makes the wait longer, the reverts later, and the release later than it had to be.