Postgres 19 verschoben: KI-Review fand zu viel

PostgreSQL 19 erscheint später als geplant. Laut der Ankündigung zur Beta 4 konnte die finale Version noch im Oktober kommen. Jetzt nennt das Projekt in der Meldung zum Release Candidate 1 vom 15.10.2026 den 19.11.2026 als Termin, mit einem zweiten Release Candidate am 12.11. Auf dem Weg dorthin sind ungewöhnlich viele Features wieder rausgeflogen. Ein Grund dafür sind LLM-gestützte Code-Reviews.

Was zurückgenommen wurde

Allein mit der Beta 4 vom 24.09.2026 hat das Team unter anderem diese Funktionen wieder entfernt:

SQL/PGQ, also Abfragen auf Property-Graphen nach dem SQL-Standard von 2023
Das Ein- und Ausschalten von Daten-Prüfsummen im laufenden Betrieb
Temporale Updates und Deletes mit FOR PORTION OF
ALTER TABLE ... MERGE PARTITIONS und SPLIT PARTITIONS
Die Funktionen pg_get_role_ddl(), pg_get_tablespace_ddl() und pg_get_database_ddl()

Die Begründung in der Ankündigung: Zuverlässigkeit geht vor, die Features können nach weiterer Arbeit in einem späteren Major-Release kommen. Peter Eisentraut, langjähriger Postgres-Committer bei EDB, kommt in seinem Blogbeitrag vom 09.10. je nach Zählweise auf acht bis zehn größere Features. Normal seien ein bis zwei pro Zyklus. Was in Version 19 bleibt, etwa REPACK (CONCURRENTLY) oder pg_plan_advice, wurde laut RC-Meldung in den letzten Wochen noch an mehreren Stellen nachgebessert.

Die Fehler waren alt, das Werkzeug ist neu

Eisentraut beschreibt das Muster so: Viele der Fehler sind eher harmlose Randfälle, die früher oft erst Jahre nach dem Release aufgefallen wären. "With LLM-assisted code review, these kinds of things can get found much faster", schreibt er. Dann sitzt man vor einer Liste von 40 Fehlerberichten. Selbst wenn jeder nur eine Korrektur von drei Zeilen braucht, kostet jeder einzelne Zeit, und irgendwann ist der Zyklus vorbei.

Mit Vibe Coding hat das laut Eisentraut nichts zu tun. Die betroffenen Features entstanden größtenteils, bevor es diese Review-Werkzeuge gab. Sein Satz dazu: "The effective quality bar has been raised after the time the feature was written and committed." Die Messlatte ist also gestiegen, nachdem der Code schon im Repository lag.

Bei SQL/PGQ kamen grundsätzliche Probleme dazu. Tom Lane, einer der bekanntesten Postgres-Entwickler, hatte laut The Register im September gewettet, dass ein Release mit diesem Feature Fehler nach sich ziehen würde, die sich erst in Version 20 beheben lassen. Eisentraut nennt neben den Reviews weitere Ursachen, darunter die viele Sicherheitsarbeit der letzten Monate.

Der eigentliche Punkt: Review gehört an den Anfang

Die Postgres-Geschichte zeigt, was passiert, wenn ein gründlicheres Review erst am Ende der Kette ansetzt. Die Fehler sind dieselben, nur der Zeitpunkt ist der schlechteste: Beta-Phase, Feature-Freeze, Release-Termin. Wer dieselben Werkzeuge schon beim Schreiben einsetzt, findet die Fehler, solange sie billig sind.

Wann der Fehler auffällt	Was er kostet
Beim Schreiben, vor dem Commit	Ein paar Minuten, der Kontext ist noch im Kopf
Im Pull Request	Eine weitere Review-Runde
In der Beta, kurz vor dem Release	Revert, verschobener Termin, Feature wandert ins nächste Jahr
Nach dem Release	Patch-Release, im schlimmsten Fall ein Fehler, der sich nur mit einer neuen Major-Version lösen lässt

Dazu kommt ein zweiter Effekt, der in der Debatte oft untergeht. Ein Review, das während der Entwicklung läuft, bringt den Entwicklerinnen und Entwicklern etwas bei. Wer zum dritten Mal hört, dass ein NULL-Fall fehlt oder eine Sperre in einer bestimmten Reihenfolge nicht hält, schreibt diesen Fehler beim vierten Mal seltener. Ein Review, das ein Jahr nach dem Commit 40 Befunde liefert, bringt diesen Lerneffekt kaum noch. Der Code ist dann fremd, auch für die eigene Autorin.

Eisentraut zieht für Postgres eine ähnliche Konsequenz. LLM-gestütztes Fuzzing finde Probleme in komplexen Feature-Kombinationen schnell, "so this probably needs to be part of feature development in the future."

Was das für eigene Projekte heißt

KI-Review lokal vor dem Commit laufen lassen, nicht erst als Gate am Pull Request. Viele Werkzeuge bieten das inzwischen, etwa als Kommando im Coding-Agenten. Die Befunde landen dann bei der Person, die den Code gerade im Kopf hat.
Wiederkehrende Befunde sammeln. Was das Review immer wieder findet, gehört in die Projektregeln, die der Agent und das Team lesen. So wird aus einzelnen Befunden eine Konvention.
Bestandscode gezielt nachprüfen, bevor die Release-Phase beginnt. Wer ein neues Review-Werkzeug einführt, sollte damit rechnen, dass es im alten Code eine Welle findet. Die gehört in eine ruhige Phase, nicht in die Woche vor dem Termin.
Für die Welle Zeit einplanen. Jeder Befund kostet Zeit, auch wenn die Korrektur klein ist. Das ist die Lehre aus Eisentrauts Rechnung mit den 40 Berichten.

Wie ein Team mit sehr vielen Änderungen pro Tag Review organisiert, hat das Claude-Code-Team bei Anthropic beschrieben: Freigabe nach Risiko der Änderung, und jeder Revert wird zum Testfall für das Review-Werkzeug. Die Zahlen dort stammen vom Hersteller selbst, das Prinzip lässt sich aber auch ohne dessen Produkt übernehmen. Warum mehr KI-Code den Review-Engpass erst einmal verschärft, steht in unserem Artikel zum Review-Stau.

Eisentraut bleibt trotz allem optimistisch. Gegenüber The Register sagte er, PostgreSQL 19 werde ein gutes Release, "and it will be very robust, after all the additional scrutiny". Und wenn die Werkzeuge nicht im selben Tempo weiter besser werden, sollte sich die Lage in den nächsten Zyklen von selbst einpendeln.