PostgreSQL 19 Delayed as AI Finds Bugs Faster Than Humans Can Fix Them

PostgreSQL 19 was originally scheduled for release on October 29. The project later announced an additional RC2 and moved the final release to November 19. The immediate reason was the unusually large number of recent fixes that needed another round of community validation.

The delay is notable because it illustrates how AI is changing the software release process. PostgreSQL core contributor Peter Eisentraut said the affected features were generally not produced by low-quality AI-generated code. Most had been completed before large language models became mature tools for programming and review. What changed was that increasingly capable AI systems began re-examining code that had passed through conventional development processes.

Key points

• Roughly eight to ten important features were removed after the beta phase began.
• Some issues were architectural and could not be resolved safely within the release window.
• Others were long-tail defects that were individually small but expensive to investigate and validate in aggregate.
• AI-assisted fuzzing can generate combinations of database features that are difficult for humans to enumerate manually.
• SQL/PGQ was among the notable features removed from PostgreSQL 19 and may return in a later release after further work.

PostgreSQL is particularly exposed to this kind of testing because its features are expected to compose freely. A new SQL capability may need to work with domains, composite types, partitioned tables, views, triggers and security-definer functions, sometimes nested through several layers. Human-written test plans cannot realistically cover every combination. An AI system can generate unusual inputs, observe failures and expand its search around suspicious paths much faster.

That creates a counterintuitive outcome: AI can improve software quality while slowing the release in the short term. Finding a defect is only the first step. Maintainers must reproduce it, determine whether it violates the intended semantics, assess its impact, design a fix and run regression tests. Even a three-line patch can carry a substantial human coordination cost when dozens of reports arrive together.

The situation was also affected by a period of intensive security work and by PostgreSQL’s growing internal complexity. The project therefore chose a conservative response rather than carrying unresolved risk into the final release. PostgreSQL 19 is not necessarily a minor version; important capabilities remain, while several deferred features may provide a starting point for PostgreSQL 20.

The broader lesson is that the effective quality bar is becoming dynamic. AI review should move earlier into feature development, but teams also need triage systems that separate serious defects, acceptable edge behavior and false positives. AI can widen the search space. Humans still have to define the product’s intended behavior and decide when the software is good enough to ship.

Source: InfoQ Chinese