1169 Commits sind zwischen dem 8. April und dem 25. September in den stabilen Zweig REL_19_STABLE eingegangen. Im gleichen Zeitfenster des Vorjahres waren es 724. Diese Zahl sagt mehr über den Zustand des PostgreSQL-Projekts als jede Roadmap. Sie ist der Hauptgrund, warum PostgreSQL 19 in diesem Jahr nicht wie gewohnt zwischen Mitte September und Mitte Oktober erscheint, sondern voraussichtlich erst im November. Die Ursache klingt paradox: Es wird zu viel gefunden, nicht zu wenig gebaut.
Ein Bild hilft. Ein großes Gebäude, über vier Jahrzehnte gewachsen, angebaut, umgebaut, immer wieder instand gehalten von Leuten, die ihr Handwerk verstanden. Jetzt kommt ein Prüfgerät auf den Markt, das Risse sichtbar macht, die seit Jahrzehnten niemand gesehen hat – nicht weil schlecht gearbeitet wurde, sondern weil das Werkzeug fehlte. Die Handwerker sind dieselben. Die Mängelliste ist explodiert. Genau das beschreibt ein langjähriger PostgreSQL-Entwickler in einem Beitrag darüber, warum sein Projekt in diesem Jahr aus dem Takt gerät.
Späte Reverts: Drei große Features fallen kurz vor dem Ziel raus
Die Zeitplanung von PostgreSQL war über ein Jahrzehnt verlässlich: Major-Release nicht vor Mitte September, nicht nach Mitte Oktober. Feature Freeze ist jedes Jahr am 8. April, danach werden neue Funktionen nicht mehr angenommen. In diesem Jahr wurden zwischen dem 27. August und dem 15. September drei größere Features wieder aus dem Release genommen: UPDATE/DELETE FOR PORTION OF, die Property-Graph-Queries nach SQL/PGQ und ALTER TABLE … MERGE PARTITION/SPLIT PARTITION. Einzelne Reverts direkt nach dem Feature Freeze sind nichts Ungewöhnliches, das passiert in vielen Jahren.
Drei große Funktionen so spät in der Beta-Phase zurückzuziehen, ist ein anderes Kaliber. Wer eine Version über Monate getestet hat, rechnet im September nicht mehr damit, dass zentrale Bausteine wegfallen. Für die Release-Verantwortlichen heißt das Nacharbeit an Dokumentation, Tests und Kompatibilitätsversprechen. Der Autor nennt die Verschiebung selbst nicht beunruhigend, ordnet sie aber als Symptom ein – und liefert die Zahlen dazu.
Die Commit-Zahlen: Der Zuwachs steckt in den Wartungszweigen
Zwischen dem 8. April 2025 und dem 25. September 2025 gingen 1037 Commits in den Master-Branch, im gleichen Zeitraum 2026 waren es 1443. Der größere Sprung liegt eine Ebene tiefer: 724 Commits landeten 2025 im Wartungszweig REL_18_STABLE, 1169 waren es 2026 in REL_19_STABLE – über 60 Prozent mehr. Solche Commits sind Korrekturen, die in einen bereits ausgelieferten oder kurz vor der Auslieferung stehenden Zweig zurückportiert werden. Sie zeigen, wie viele Fehler tatsächlich repariert wurden.
Ältere Releases machen die Verschiebung deutlicher. Für REL_17_STABLE wurden im Vergleichszeitraum 2025 insgesamt 248 Commits verbucht, für REL_18_STABLE 2026 waren es 433 – ein Plus von über 74 Prozent. Es geht also nicht nur um Fehler in der kommenden Version, sondern um Code, der seit Jahren in Produktion läuft. Die Reparaturen an alternder Software haben sich binnen eines Jahres fast verdoppelt, ohne dass mehr Leute daran arbeiten.
Vierzig Jahre Code, die plötzlich lesbar werden
Die Git-Historie von PostgreSQL reicht – konvertiert aus CVS – mehr als dreißig Jahre zurück, die ersten Codezeilen entstanden ein Jahrzehnt davor. Daraus ist ein großer, alter und komplexer Bestand geworden. Dass darin Fehler stecken, war immer bekannt und hat den Erfolg des Projekts nie verhindert. Software wird nicht dadurch unbrauchbar, dass sie Fehler enthält, sondern dadurch, dass niemand sie findet, bevor sie Schaden anrichten.
Verändert hat sich die Ökonomie der Fehlersuche. Ein Sprachmodell überfliegt Code, den ein Mensch in derselben Zeit nur oberflächlich sichten würde, und meldet Auffälligkeiten, die vorher niemandem aufgefallen sind. KI findet Bugs in PostgreSQL-Code inzwischen schneller, als das Projekt sie abarbeiten kann. Das Reparieren ist ebenfalls leichter geworden, aber nicht im selben Maß. In dieser Lücke steckt die Verspätung von PostgreSQL 19: Auf der einen Seite steht ein Werkzeug, das im Minutentakt Fehlerkandidaten ausspuckt, auf der anderen eine Handvoll Committer mit begrenzter Zeit.
LLM-Bugfixing ist kein Selbstläufer: Der Review bleibt menschlich
Der naheliegende Einwand: Die Modelle könnten die Fehler doch gleich selbst beheben. Teilweise können sie das, und sie tun es auch. Nur sind die vorgeschlagenen Patches nicht immer korrekt und nicht immer konform mit den Konventionen, die bei PostgreSQL gelten. Ein Patch, der kompiliert und den Testlauf besteht, ist noch lange kein Patch, den ein Committer verantworten will. Er muss gelesen, geprüft, angepasst und eingeordnet werden. Das dauert.
Die zweite Bremse ist weniger offensichtlich. Zeit, die für das Review der kommenden Version eingeplant war, floss in Sicherheitsmeldungen und Korrekturen für längst veröffentlichte Zweige. Was in v19 gehört und was nicht, ließ sich dadurch später klären als üblich. Die späten Reverts sind also kein Zeichen von Nachlässigkeit, sondern Folge davon, dass dieselben Leute an zwei Fronten gleichzeitig gebraucht wurden. Für KI im Softwaretesting ist das ein wichtiger Befund: Das Werkzeug verschiebt den Engpass, es beseitigt ihn nicht.
Die offene Frage: Wie holt man Jahrzehnte an Fehlern auf?
Kurzfristig sieht der Autor die Verschiebung gelassen. Ein paar Wochen sind gemessen an einem Release-Zyklus kein Drama, und die Verzögerung kommt aus dem Qualitätsanspruch des Projekts, nicht aus Chaos. Die langfristige Perspektive fällt in seinem Beitrag unbehaglicher aus. Wenn vierzig Jahre unentdeckte Fehler im Bestand liegen und ein Modell sie nun zuverlässig findet, stellt sich die Frage, wie dieser Rückstand jemals aufgeholt werden soll – und welche Kraft für neue Funktionen bleibt.
Eine fertige Antwort hat der Entwickler nicht. Er schreibt, dass er und viele andere derzeit daran arbeiten, eine zu finden. An seiner Einschätzung der Codebasis hält er fest: PostgreSQL sei einer der saubersten und hochwertigsten Bestände, mit denen er je gearbeitet habe, und die Trefferquote der Modelle ändere daran nichts. Im Gegenteil – wäre der Code fehlerhafter, gäbe es noch mehr Funde.
Was die Verspätung von PostgreSQL 19 konkret bedeutet
Wer einen Wechsel plant: Der PostgreSQL-19-Release verschiebt sich voraussichtlich in den November, eine weitere Verzögerung ist nicht ausgeschlossen. Wer Migrationsfenster, Schulungen oder Verträge an den gewohnten Septembertermin gehängt hat, sollte sie nach hinten schieben statt auf ein Wunder zu hoffen. Was im November kommt, hat weniger bekannte Baustellen als eine Version, die im September unter Zeitdruck freigegeben worden wäre.
Interessanter als das Datum ist das Muster dahinter. Jede Codebasis, die über Jahre gewachsen ist, enthält Fehler, die kein Review gefunden hat, weil niemand so lange und so geduldig hinschauen konnte. Diese Annahme ist überholt. Wer heute Software entwickelt, schreibt für ein Publikum, das innerhalb von Stunden prüft, was früher jahrzehntelang unbemerkt blieb. Das ist unangenehm. Aber es ist auch der Grund, warum die PostgreSQL-Entwicklung davon profitiert – vorausgesetzt, die Zahl der Menschen, die Patches prüfen, wächst mit der Zahl der Funde.
Quelle: neon.com
