Die PostgreSQL Global Development Group hat die Veröffentlichung von PostgreSQL 19, einer der folgenreichsten Zeitplanänderungen in der 30-jährigen Geschichte der Open-Source-Datenbank, verzögert, nachdem die LLM-unterstützte Codeüberprüfung mehr Mängel zutage gefördert hatte, als die Freiwilligengemeinschaft vor der Veröffentlichung beheben konnte.

Laut einem am 16. Oktober veröffentlichten Bericht von The Register wird die Veröffentlichung, die ursprünglich für Ende September oder Anfang Oktober geplant war, nun voraussichtlich um den 19. November allgemein verfügbar sein. Parallel zur Verzögerung haben Entwickler zwischen acht und zehn wichtige Funktionen zurückgenommen und sie auf PostgreSQL 20 des nächsten Jahres verschoben. Weitere Informationen zu dieser Geschichte finden Sie in unserer neueste KI-Entwicklungen.

Der Qualitätsbalken hat sich in der Mitte des Zyklus verschoben

Peter Eisentraut, Vizepräsident des PostgreSQL-Beratungsunternehmens EDB und einer der führenden Committer des Projekts, legte die Begründung in einem Blogbeitrag mit dem Titel „Die Rückkehr wird fortgesetzt, bis sich die Moral verbessert“ dar, der am 9. Oktober veröffentlicht wurde.

Laut Eisentraut wiesen einige der zurückgesetzten Funktionen erhebliche architektonische Mängel auf, die „schnell und während der Betaphase“ schwer zu beheben gewesen wären. Das ungewöhnlichere Problem war jedoch eine lange Reihe kleinerer Probleme, die in früheren Veröffentlichungszyklen einfach nie rechtzeitig erkannt worden wären.

Die von LLM unterstützte Codeüberprüfung, schrieb er, deckte „relativ harmlose Probleme mit verschiedenen Randfällen“ auf, die in der Vergangenheit möglicherweise erst Jahre nach der Veröffentlichung bemerkt wurden und typischerweise in den fünf Jahren nach einer Veröffentlichung in Form von Fehlerbehebungen ans Licht kamen. Bei der KI-Überprüfung treten dieselben Mängel jetzt auf, bevor der Code ausgeliefert wird.

„Mit der LLM-unterstützten Codeüberprüfung können solche Dinge viel schneller gefunden werden, und dann steht man vor einer Liste mit vierzig Fehlerberichten“, schrieb Eisentraut. „Selbst wenn jeder von ihnen im Durchschnitt nur eine dreizeilige Lösung erfordert, gibt es einen festen Mehraufwand für die Bewältigung jedes dieser Probleme, und dann läuft einem die Zeit davon.“

Der Zeitpunkt des Qualitätswandels ist ebenso wichtig wie sein Ausmaß. Als die wichtigsten Funktionen von PostgreSQL 19 geschrieben wurden, waren die LLM-basierten Überprüfungstools noch nicht so leistungsfähig wie in den Monaten vor der Veröffentlichung. Nachdem der Code bereits festgeschrieben worden war, legte das Projekt seine eigene Qualitätsmesslatte effektiv höher.

„Die Messlatte für die tatsächliche Qualität wurde nach der Zeit, in der das Feature geschrieben und festgeschrieben wurde, höher gelegt“, sagte Eisentraut. „Wenn sich die Fähigkeiten der LLM-unterstützten Codeüberprüfung nicht im aktuellen Tempo weiter verbessern, sollte sich diese Situation für zukünftige Entwicklungszyklen regeln.“

Nicht „Vibe Coding“

Eisentraut achtete sorgfältig darauf, die Situation von einer schlampigen KI-generierten Entwicklung zu unterscheiden. Er betonte, dass die Zurücksetzungen nicht das Ergebnis von „Vibe-Codierung“ seien, da die Technik nicht verfügbar war, als die meisten neuen Funktionen von PostgreSQL 19 geschrieben wurden. Die Probleme der Datenbank waren auf eine bessere Überprüfung und nicht auf eine schlechtere Erstellung zurückzuführen.

Diese Unterscheidung macht die Episode für die gesamte Softwarebranche so bemerkenswert. Die ausgereifteste Open-Source-Datenbank der Welt – erstmals 1986 von Michael Stonebraker vorgeschlagen und 1995 in PostgreSQL umbenannt, als Andrew Yu und Jolly Chen die POSTQUEL-Abfragesprache durch SQL ersetzten – scheiterte nicht, weil die Entwickler nachlässig wurden. Es verzögerte sich, weil KI-Tools die bestehende Prüfung erheblich effektiver machten.

Ein Flaggschiff-Unfall: Diagrammabfragen

Die herausragendste Funktion der Veröffentlichung ist die Unterstützung von SQL Property Graph Queries (SQL/PGQ), einer Graph-Matching-Funktion, die 2023 Teil des SQL-Standards wurde. Mit der Syntax können Entwickler Beziehungen zwischen Knoten, die durch Kanten verbunden sind, direkt in SQL untersuchen, und die Implementierung von PostgreSQL war eine der am meisten erwarteten Funktionen von PostgreSQL 19.

Es wurde wegen ungelöster Korrektheitsprobleme entfernt. Der PostgreSQL-Mitarbeiter Tom Lane hatte laut The Register vor der Entscheidung gewarnt: „Zum jetzigen Zeitpunkt wäre ich bereit zu wetten, dass es nach der Veröffentlichung Fehlerentdeckungen geben wird, die bis zur Version 20 nicht behoben werden können, wenn wir es in Version 19 ausliefern.“

Die zurückgesetzten Funktionen, einschließlich SQL/PGQ, werden voraussichtlich in PostgreSQL 20 landen. Bis vor Kurzem ging man davon aus, dass diese Version überhaupt keine neuen Funktionen enthielt – eine auf Stabilisierung ausgerichtete Nachfolgeversion. Es wird nun wahrscheinlich die verdrängte Arbeit von PostgreSQL 19 übernehmen.

Was im November noch versendet wird

Trotz der Verzögerungen versprach Eisentraut, dass PostgreSQL 19 immer noch „eine großartige Veröffentlichung“ sein werde. Zu den beibehaltenen Funktionen gehört REPACK CONCURRENTLY, das Speicherplatz ohne den tabellensperrenden VACUUM FULL-Vorgang zurückgewinnt, der lange Zeit ein Problem für Produktionsdatenbanken darstellte.

„Und es wird nach all der zusätzlichen Prüfung sehr robust sein“, sagte er.

Ein Signal für jedes Engineering-Team

Die PostgreSQL-Episode ist eines der klarsten Beispiele aus der Praxis, wie die Überprüfung von KI-Code nicht nur die Art und Weise verändert, wie Software erstellt wird, sondern auch, was „erledigt“ bedeutet. Ein Projekt, das seit Jahrzehnten zuverlässige Veröffentlichungen im jährlichen Turnus liefert, stellte fest, dass seine neuen Überprüfungstools mehr umsetzbare Erkenntnisse lieferten, als seine Betreuer innerhalb des bestehenden Kalenders verarbeiten konnten.

Für Unternehmensteams, die auf KI-unterstützte Entwicklung setzen, ist die Lektion aus der PostgreSQL-Community maßvoll: KI-Überprüfung kann die Qualität erheblich steigern, aber Unternehmen benötigen die Überprüfungskapazität – menschliche Zeit, Triage-Prozess und Zeitmangel –, um zu absorbieren, was die Modelle finden. Die Alternative ist die, die PostgreSQL gewählt hat: das Veröffentlichungsdatum verschieben.

Für Datenbankadministratoren, die Upgrades planen, ist der praktische Leitfaden derselbe wie bei jeder Hauptversionsmigration: Testen Sie Workloads mit PostgreSQL 19-Betas, rechnen Sie jedoch mit der produktionsbereiten Veröffentlichung um den 19. November herum und nicht mit dem ursprünglichen Herbstfenster.

Während sich KI-Überprüfungstools im Open-Source-Ökosystem verbreiten – der Linux-Kernel hat kürzlich Offenlegungsregeln für die Nutzung von KI-Tools formalisiert, eine Debatte, die The Register aufmerksam verfolgt hat – bietet die Erfahrung von PostgreSQL eine Vorschau. Eine bessere Überprüfung findet mehr Fehler. Weitere Fehler brauchen Zeit, um behoben zu werden. Und manchmal besteht die gesündeste Reaktion auf eine KI, die mehr Fehler findet, als Menschen bewältigen können, darin, einfach später zu versenden.

---

Bleib vorne bei KI

Die neuesten KI-Nachrichten, Analysen und Durchbrüche – alles an einem Ort.

Mehr KI-Nachrichten lesen →