Robert Haas, Core-Committer bei PostgreSQL, hat am 30. Oktober einen Blogbeitrag veröffentlicht, in dem er erklärt, warum das große Release in diesem Jahr später kommt. In den vergangenen zehn Jahren erschienen die PostgreSQL-Hauptversionen stets zwischen Mitte September und Mitte Oktober, PostgreSQL 19 wird dagegen sehr wahrscheinlich erst im November kommen, möglicherweise sogar noch später. Seine Begründung passt in einen Satz:
„The short answer is that LLMs happened.“ (Kurz gesagt: Die LLMs sind passiert.)
Haas ist heute Senior Staff Software Engineer bei Databricks. Der Beitrag gibt seine persönliche Einschätzung wieder; ein neues Veröffentlichungsdatum nennt er nicht.
Drei große Features im letzten Monat zurückgezogen
Der jährliche Feature-Freeze liegt am 8. April, und dass nach dem Freeze Features wieder entfernt werden, ist nichts Ungewöhnliches. Neu ist in diesem Jahr der Zeitpunkt und das Gewicht: Zwischen dem 27. August und dem 15. September wurden nacheinander drei große Features zurückgenommen.
UPDATE/DELETE FOR PORTION OF- SQL-Property-Graph-Abfragen (SQL/PGQ)
ALTER TABLE ... MERGE PARTITION / SPLIT PARTITION
Haas zufolge wird auch in anderen Jahren zurückgezogen, aber selten so spät und selten gleich mehrere große Features auf einmal.
Sechzig Prozent mehr Commits, aber nicht nachlässigere Committer
Er legt das Zeitfenster jedes Jahr auf den 8. April bis 25. September fest und vergleicht die Menge der Korrekturen. Im Vorjahr gingen 724 Commits in REL_18_STABLE, in diesem Jahr sind es 1169 in REL_19_STABLE, ein Plus von mehr als 60 Prozent. Beim jeweils vorherigen stabilen Branch waren es im Vorjahr 248 Commits in REL_17_STABLE und in diesem Jahr 433 in REL_18_STABLE, ein Anstieg von mehr als 74 Prozent.
Haas glaubt nicht, dass diese zusätzlichen Commits daher rühren, dass schlechter programmiert wird. Seiner Einschätzung nach arbeiten die Committer ungefähr so sorgfältig wie in früheren Jahren; verändert hat sich die Phase des Auffindens: Viele Leute setzen LLMs ein, um Fehler in PostgreSQL aufzuspüren, und melden sie direkt.
„What's different now is that it's become vastly easier to find those bugs.“ (Neu ist, dass es unvergleichlich viel leichter geworden ist, diese Bugs zu finden.)
Diese Zuschreibung hat eine Lücke: Die Commit-Historie verzeichnet nicht, wer einen Bug mit welchem Werkzeug entdeckt hat, und der Beitrag nennt auch keinen Anteil der LLM-Berichte daran. Die genannten Zuwächse sind gemessen; „vor allem wegen LLMs“ ist die Beobachtung eines langjährigen Committers.
Der Engpass ist die manuelle Prüfung
Der Verzögerungsmechanismus hat zwei Ebenen. Erstens: Mehr Bugs bedeuten schlicht mehr Aufwand beim Beheben. LLMs können Patches entwerfen, doch ein Patch ist nicht zwingend korrekt und nicht zwingend im Einklang mit den Projektkonventionen, und am Ende muss ein Committer jeden einzelnen prüfen, bevor er eingespielt wird. Die zweite Ebene ist subtiler: Zeit, die eigentlich für die Prüfung der Inhalte der neuen Version gedacht war, wird von Sicherheitsproblemen und Defekten in älteren Branches aufgezehrt, sodass auch die Entscheidung, welche Features zurückgezogen werden sollen, später fällt.
Das lässt sich neben das Firefox-Experiment von Epoch AI aus den Tagen davor legen. Epoch hat die Angriffsseite gemessen: Mit GLM 5.3 wurden Exploits in dem Zeitfenster geschrieben, das nach Veröffentlichung eines Patches offen bleibt, bei Rechenkosten von rund 1000 US-Dollar pro Version. Haas beschreibt die Wartungsseite: Dieselbe Fähigkeit, auf ein jahrzehntealtes Projekt angewendet, lässt zuerst die Zahl der Berichte steigen, während die Zahl der Leute, die Code prüfen können, nicht mitwächst. Die gemeinsame Variable beider Seiten sind die Kosten, Schwachstellen zu finden, und sie fallen schneller als die Kosten, sie zu beheben.
Das ist auch für Teams in China keine ferne Angelegenheit. Viele Cloud-Datenbankprodukte bauen auf PostgreSQL auf und entwickeln es weiter; wenn das Aufkommen an Merges im Upstream um sechzig bis siebzig Prozent steigt, dürfte auch der Aufwand für das Nachziehen der Patches downstream entsprechend wachsen. Wie groß die Auswirkung tatsächlich ist, dazu hat bislang kein Anbieter Zahlen genannt.
Vierzig Jahre Altbestand sind der eigentliche Druck auf lange Sicht
Die Verspätung selbst beunruhigt Haas nicht. Er sagt, im langen Zyklus sei das keine große Verzögerung, und sie rühre vom Qualitätsanspruch des Projekts her. Er betont zudem, dass die Tatsache, dass KI diese Probleme findet, seine Einschätzung der Qualität der Codebasis nicht verändert habe.
Unsicher macht ihn das, was danach kommt. Das Projekt hat rund vierzig Jahre an Fehlern angesammelt, die Menschen nicht entdeckt haben, LLMs können davon einiges ausgraben, und in seinen eigenen Worten: „how are we ever going to catch up“. Künftig wird jedes neue Feature von einer KI durchgesehen werden, was Druck bedeutet, den Code aber auch solider machen kann. Eine Lösung nennt er nicht, sagt aber, dass er und viele andere daran arbeiten, einen Weg zu finden.
An welchem Tag PostgreSQL 19 schließlich erscheint, hängt von den nächsten Ankündigungen des Release-Teams ab.
Quellen: persönlicher Blog von Robert Haas; CocoLoop; öffentlicher Experimentbericht von Epoch AI; die Commit-Statistiken der Branches folgen der Abgrenzung in Haas' Beitrag und wurden nicht eigens nachgerechnet.