PostgreSQL 19 wird ohne SQL/PGQ ausgeliefert: Die richtige Entscheidung

Wer schon einmal einen Postgres-Primärserver jenseits eines Terabytes betrieben hat, kennt das: Man starrt auf einen Bloat-Report und rechnet die Ausfallzeit durch. Entweder akzeptiert man das Diskwachstum, plant ein Wartungsfenster, das niemand will, oder greift zu einem Drittanbieter-Tool und hofft, dass die Replikationstopologie mitspielt. PostgreSQL 19 löst dieses Problem endlich im Kern. Gleichzeitig verabschiedet sich die neue Version still und leise von einem angekündigten Feature, das noch nicht reif war.

Das Problem

Kurz zusammengefasst: Wie The Register berichtete, haben die PostgreSQL-Entwickler die geplante SQL/PGQ-Graph-Query-Unterstützung aus Version 19 wegen ungelöster Bugs zurückgezogen. Eine vierte Beta erscheint am 24. September, und das endgültige Release-Datum ist noch nicht bestätigt. Tom Lane, ein langjähriger Contributor, brachte es auf den Punkt: „An diesem Punkt würde ich darauf wetten, dass wir nach dem Release Bug-Entdeckungen haben werden, die erst in Version 20 behoben werden können, wenn wir es jetzt in Version 19 ausliefern." Tom Kincaid, SVP of Software Engineering bei EDB, bestätigte die Streichung und erklärte, die Community wolle vor der Auslieferung noch einige Dinge klären.

SQL/PGQ ist relevant, weil es 2023 Teil des SQL-Standards wurde und eine portable Syntax bietet, um Knoten und Kanten direkt in der relationalen Datenbank abzufragen – ohne auf eine separate Graph-Datenbank wechseln zu müssen. Für Teams, die neben Postgres eine zweite Graph-Datenbank für Betrugsgrafen, KYC-Netzwerke, Affiliate-Hierarchien oder Ad-Tech-Attributionspfade betreiben, war das Versprechen erheblich: den Sidecar abschalten, eine einzige Quelle der Wahrheit behalten, eine Backup-Strategie, eine HA-Lösung. Dieses Versprechen verschiebt sich nun auf Version 20.

Der Betriebsschmerz, der nie in den Marketing-Folien auftauchte, ist das, was dieses Release tatsächlich löst. VACUUM FULL schreibt eine Tabelle neu, um den von veralteten Zeilenversionen belegten Speicherplatz zurückzugewinnen und ihn dem Betriebssystem zurückzugeben. Während des gesamten Vorgangs hält es eine exklusive Tabellensperre, die jedes Lesen und jeden Schreibvorgang blockiert. Bei einer stark frequentierten OLTP-Tabelle ist das kein Wartungsvorgang. Das ist ein Ausfall mit angehängtem Change-Ticket.

Kincaid beschrieb das Muster, das ich in Dutzenden von On-Call-Rotationen beobachtet habe: „Anrufe mitten in der Nacht entstanden dadurch, dass jemand VACUUM FULL ausgeführt hat und die Kunden keinen Zugriff auf die Daten hatten oder jemand wissen wollte, warum das gerade läuft." Jeder DBA, der das liest, nickt gerade zustimmend. Bloat akkumuliert sich, Autovacuum kann bei einer hochfrequentierten Tabelle nicht mithalten, irgendwann drückt jemand den Auslöser bei VACUUM FULL – und der Alarm geht los.

Die verfügbaren Optionen

Vor Version 19 hatten Teams drei realistische Möglichkeiten, Speicherplatz auf einer aktiven Tabelle zurückzugewinnen – und keine davon war angenehm.

Option eins: VACUUM FULL einplanen und die Ausfallzeit in Kauf nehmen. Das funktioniert für interne Reporting-Tabellen oder alles, was sich während eines Niedriglastfensters einfrieren lässt. Für einen iGaming-Betreiber mit Live-Wetten oder ein Fintech beim Position Settling gibt es kein Niedriglastfenster, das lang genug dauert. Produktionsvorfälle, die ich erlebt habe, beginnen meistens genau hier – wenn jemand davon ausgeht, dass es bei einer 400-GB-Tabelle „schnell gehen wird".

Option zwei: pg_repack als Extension. Die Community-Extension erledigt die parallele Neuerstellung seit Jahren und funktioniert. Sie bringt aber auch operativen Aufwand mit sich: Installation und Versionierung der Extension auf allen Replikas, Überwachung der temporären Tabellen, Umgang mit Sonderfällen bei Replikations-Slots und die Hoffnung, dass der verwaltete Postgres-Anbieter sie unterstützt. Manche tun es, andere nicht. Schlägt eine Neuerstellung auf halbem Weg fehl, ist die Bereinigung manuell und stressig.

Option drei: Tabelle partitionieren und alte Partitionen löschen. Das ist die langfristig richtige Antwort für Zeitreihen- und überwiegend append-lastige Workloads und sollte die Standardlösung für jede Tabelle sein, die voraussichtlich mehrere hundert Gigabyte überschreiten wird. Bei einer bestehenden Monstertabelle, die nie partitioniert wurde, hilft das heute nicht weiter. Eine 2-TB-Tabelle im Live-Betrieb nachträglich zu partitionieren, ist ein eigenes, mehrwöchiges Projekt.

PostgreSQL 19 fügt eine vierte Option hinzu: den neuen REPACK-Befehl mit dem Modifier CONCURRENTLY. Normales REPACK verhält sich wie VACUUM FULL und hält die exklusive Sperre während des gesamten Vorgangs. REPACK CONCURRENTLY erlaubt anderen Transaktionen, während des größten Teils der Operation auf die Tabelle zuzugreifen, und benötigt nur kurz eine exklusive Sperre beim Einspielen der neu geschriebenen Tabellen- und Indexdateien. Das ist genau die Art von Operation, die Teams seit einem Jahrzehnt im Kern haben wollten.

Meine Einschätzung: Damit wandert pg_repack's Aufgabe still und leise in die Basisinstallation, was für Managed-Database-Kunden ein größerer Schritt ist als für selbst gehostete Umgebungen. Wer bei einem Cloud-Anbieter betreibt, der Extensions historisch langsam auf die Whitelist setzt, bekommt das parallele Repack nun automatisch mit dem Upgrade auf Version 19. Das ist ein Einkaufsgespräch weniger und ein Fehlermodus weniger im Runbook.

Auf der SQL/PGQ-Seite sind die Alternativen unverändert. Den vorhandenen Graph-Store behalten (Neo4j, Memgraph, AGE on Postgres) oder Beziehungen mit rekursiven CTEs modellieren und die Query-Planner-Kosten in Kauf nehmen. Nichts Neues in diesem Zyklus zu bewerten. Zurück zu Version 20 schauen. Die PostgreSQL-Dokumentation liefert die genaue REPACK-Syntax, wenn die Release Notes erscheinen.

Was Engineering-Teams konkret tun sollten

Erstens: Keine Roadmaps rund um SQL/PGQ umschreiben. Wenn der Plan für 2026 vorsah, einen Graph-Sidecar in Q4 abzulösen, ist dieser Plan hinfällig. Die Migration auf frühestens Ende 2027 verschieben – in der Annahme, dass Version 20 im üblichen Jahrestakt erscheint und PGQ es tatsächlich hineinschafft. Auf unveröffentlichte Features zu wetten hat Teams, mit denen ich gearbeitet habe, mehr als einmal schlecht ergangen. Lanes „Dinner wetten"-Zitat ist höfliches Ingenieur-Sprechen für „das wird uns noch heimsuchen." Das sollte man ernst nehmen.

Zweitens: Bloat jetzt prüfen, bevor Version 19 erscheint. Die zehn Tabellen mit dem höchsten Dead-Tuple-Verhältnis und physischem Bloat identifizieren. Nach Geschäftskritikalität und Sperr-Toleranz priorisieren. Das sind die REPACK CONCURRENTLY-Kandidaten für die ersten neunzig Tage nach dem Upgrade. Eine priorisierte Liste sollte bereitstehen, kein Feuerwehreinsatz.

Drittens: Das Upgrade auf Version 19 als zweiphasiges Rollout behandeln. Phase eins: Version 19 auf Read-Replikas und nicht-kritischen Clustern einsetzen, Backup- und PITR-Tooling validieren, sicherstellen, dass das Monitoring den neuen Befehl erfasst. Phase zwei: REPACK CONCURRENTLY gegen einen Staging-Klon der am stärksten aufgeblähten Tabelle ausführen und die tatsächliche Dauer der kurzen exklusiven Sperre beim Swap-Schritt messen. „Typischerweise nur kurz gehalten" ist die Formulierung in der Dokumentation. Die konkrete Hardware, der Replikations-Lag und das Lock-Contention-Profil bestimmen, was „kurz" für die eigene Umgebung bedeutet.

Viertens: Wer derzeit für ein Drittanbieter-Repack-Tool oder eine Extension-Management-Schicht zahlt, die hauptsächlich zur Unterstützung von pg_repack existiert, sollte einen Review-Termin sechs Monate nach dem Upgrade einplanen. Möglicherweise lässt sich der Stack vereinfachen.

Fallstricke und Sonderfälle

Die kurze exklusive Sperre beim File-Swap ist immer noch eine Sperre. Bei einer Tabelle mit Sub-Millisekunden-Latenz-SLOs und vielen parallelen Schreibvorgängen kann selbst eine kurze Sperre genug Transaktionen aufstauen, um den Connection Pool zu überlasten. Mit produktionsrepräsentativer Last testen, nicht mit einem synthetischen Benchmark. Die unbequeme Wahrheit: Teams, die „concurrent" mit „keine Auswirkungen" gleichsetzen, werden überrascht.

Das Replikationsverhalten ist das zweite zu prüfende Element. Jeder Vorgang, der eine Tabelle neu schreibt, erzeugt erhebliches WAL. Wenn Replikas geografisch weit entfernt oder bandbreitenbeschränkt sind, sollte man während des Repacks mit einem Lag-Spike rechnen und sicherstellen, dass der Lesetraffic ihn tolerieren oder sauber failovern kann. Es empfiehlt sich, OpenTelemetry-Spans um den Vorgang zu legen, um die Anwendungslatenz mit dem Neuerstellungsfenster zu korrelieren.

Drittens: Den freien Festplattenplatz im Auge behalten. Eine parallele Neuerstellung benötigt genug freien Speicher, um eine zweite Kopie der Tabelle samt Indizes zu halten, bis der Swap abgeschlossen ist. Bei einer 500-GB-Tabelle mit drei Indizes ist das kein Rundungsfehler. Entsprechend vorsorgen – sonst schlägt der Vorgang auf halbem Weg fehl und hinterlässt manuellen Aufräumbedarf.

Schließlich: Beta-Tests nicht überspringen, weil „es ja nur ein Repack-Befehl ist". Dasselbe Release, das genug Bedenken geweckt hat, um SQL/PGQ herauszunehmen, liefert auch REPACK. Beta 4 nach dem 24. September gegen eine Kopie des eigenen Workloads laufen lassen. Besser, den Sonderfall selbst zu finden, als um 3 Uhr nachts mit wartenden Kunden.

Die wichtigsten Erkenntnisse

• SQL/PGQ ist nicht in Version 19 enthalten. Jeder Roadmap-Punkt, der native Graph-Queries in Postgres dieses Jahr voraussetzte, muss auf Version 20 verschoben oder auf vorhandene Graph-Stores und rekursive CTEs zurückgefallen werden.
• REPACK CONCURRENTLY ist das unterschätzte Feature. Es bringt pg_repack's Funktion in den Kern – mit nur einer kurzen exklusiven Sperre beim File-Swap anstelle der durchgehenden Sperre, die VACUUM FULL erfordert.
• Bloat vor dem Upgrade prüfen. Eine priorisierte Liste der zuerst neu zu schreibenden Tabellen bereithalten, um im ersten Quartal nach dem Upgrade handlungsfähig zu sein statt im Stress.
• Das Swap-Fenster unter Last testen. „Kurz" ist workload-abhängig. Die Sperrdauer auf Staging mit realistischer Parallelität messen, bevor man gegen eine kundenseitige Tabelle vorgeht.
• Die Streichung verdient Anerkennung. Ein fehlerhaftes Headline-Feature vor dem Release zurückzuziehen ist die richtige Entscheidung. Es ist genau das Verhalten, das man von einer Datenbank erwartet, der man Geld und Kundendaten anvertraut.