AI Found the Defects Faster Than Anyone Could Fix Them. PostgreSQL Cut the Features. ERP Projects Cut the Testing.

What PostgreSQL actually did

PostgreSQL 19 reached its first release candidate on 15 October 2026. The project's announcement sets general availability at 19 November 2026, with a second release candidate on 12 November so that day's fixes land before GA. The roadmap page, at the time of writing, still says October 2026.

Getting there cost features. The Beta 4 announcement of 24 September names four reverted outright: SQL/PGQ property graph queries, online enabling and disabling of data checksums, temporal updates and deletes via FOR PORTION OF, and ALTER TABLE partition merge and split. The stated reason is four words long: "PostgreSQL must be reliable".

On 9 October, Peter Eisentraut, a PostgreSQL committer, put the total higher: "about 8 to 10 significant features, depending on how you count, have been reverted" since beta began. His explanation should interest any ERP delivery lead: "with LLM-assisted code review, these kinds of things can get found much faster."

Two details the coverage garbled

First, the number. Several write-ups reported that AI review found forty bugs. Eisentraut's forty illustrates workload rather than counting anything: he describes "staring at a list of like forty defect reports", adding that "even if each of them requires only a three-line fix on average, there is a fixed overhead". No total was published.

Second, the framing. This has been written up as a release delayed by AI. The project never described it that way, and Eisentraut records the opposite decision: "the community preferred trying to stick to the release schedule rather than delaying to get more fixes in." Both are true and worth separating. The date did move, from the October the roadmap still advertises to 19 November. But the response to the defect list was to cut scope, not to extend the date far enough to fix everything: the date moved by weeks, the functionality by a major version.

The constraint is disposition, not detection

The three-line fix with a fixed overhead is the whole lesson, and it transfers. On an ERP implementation a defect costs almost nothing to raise and a great deal to close. Someone must reproduce it, set a severity, decide whether it is a bug, a configuration choice or a misread process, apply a fix, retest, check nothing else moved, and update the evidence.

That overhead is constant per defect and almost entirely human. Detection capacity, by contrast, is elastic: generated scripts, automated regression passes and AI-assisted review all scale with compute. Teams keep buying the cheap half. Earlier this month we looked at what the 2026 functional testing data says about AI-written test cases, where the commonest use of AI was writing the scripts. More scripts, more findings; the number of people who can close one before Friday is unchanged.

So the useful question when planning a cycle is not how many scripts you can execute, but how many defects you can disposition per day.

When the quality bar moves after sign-off

Eisentraut makes a second observation with no standard name in ERP delivery: "the effective quality bar has been raised after the time the feature was written and committed." Code that passed review under one standard is judged under a stricter one, because the tooling improved in between.

The ERP equivalent is a configuration decision approved in month two, re-examined in cycle two of UAT by people who now understand the process far better. The approval was not negligent and the finding is not a defect, but a log offering only "bug" and "not a bug" has nowhere to put it.

A third disposition is worth having: accepted, with the decision and the accepting name against it, kept with the UAT sign-off record rather than in somebody's inbox.

The choice ERP projects make instead

PostgreSQL could remove four named features and publish the list because no customer had a contractual go-live date pinned to SQL/PGQ. An ERP programme has the opposite shape: the date is in a board paper and the scope was agreed as a whole.

When cycle two produces more defects than the calendar can absorb, three things can give: the date, the scope, or the testing. The first two need a sponsor's agreement; the third needs nobody's permission. So scripts are marked complete because a similar one passed, the last stretch of the suite is never run, and the familiar UAT failure patterns reassert themselves.

Cutting the testing is defensible if it is deliberate and written down, and indefensible by attrition, because then nobody can say afterwards which risk was accepted or by whom.

What to change in your next cycle

Budget disposition hours, not just execution hours. Put a number on the defects per day your team can close, retest and evidence included, and compare it with cycle one's defect rate. If the arithmetic does not reach the date, you know in week one, not the final fortnight.

Separate "not executed" from "passed". Opposite states, routinely conflated, which is the structural weakness of running UAT on spreadsheets: a blank cell reads as either.

Publish what you cut. The transferable practice is not the reverting; it is that the reverted list was named in the announcement. A go-live note stating which scripts were not executed, which defects remain open at what severity, and who accepted each is the ERP version, and it takes an afternoon.