Postgres 19 Beta: REPACK landet im Core, Autovacuum wird erwachsen

Wer schon einmal um 3 Uhr morgens ein Wartungsfenster eingeplant hat, nur um VACUUM FULL auf einer aufgeblähten Auftragstabelle auszuführen, kennt die wahren Kosten von Postgres-Operationen: nicht die Lizenzgebühren, sondern die Arbeitsstunden, die für das Überwachen von Sperren draufgehen. Durch diese Brille sollte man Postgres 19 Beta betrachten. Das Highlight-Feature ist nicht die glänzende SQL-Property-Graph-Abfrage, sondern die unscheinbare Infrastruktur, die endlich in den Core wandert.

Die Beta erschien im Juni, und die für Plattformteams wichtigste Release-Note besteht aus drei Wörtern: REPACK CONCURRENTLY. Meine Einschätzung: Dieses Release verabschiedet still und leise eine ganze Klasse von nächtlichen Incidents.

Was passiert ist

Postgres 19 ging mit einer Feature-Liste in die Beta, die wie eine Wunschliste aus einem Jahrzehnt produktiver Kriegsgeschichten wirkt – wie Snowflake in einem ausführlichen Bericht vom 18. Juni 2026 von Craig Kerstiens beschrieb. Das Kernstück für Operatoren ist ein neuer REPACK-Befehl, der direkt in den Core integriert wurde, einschließlich REPACK CONCURRENTLY. Jahrelang war die Antwort auf Table Bloat ohne Downtime pg_repack – eine Drittanbieter-Erweiterung, die eine Lücke füllte, die das Ökosystem nicht ignorieren konnte. Diese Lücke ist jetzt geschlossen.

Das Partitionierungsfeature erhielt zwei lang erwünschte Befehle. ALTER TABLE ... MERGE PARTITIONS ermöglicht das Zusammenführen von orders_2026_q1 und orders_2026_q2 in eine einzige orders_2026_h1. ALTER TABLE ... SPLIT PARTITION erlaubt es, orders_2026_q3 in drei monatliche Unterpartitionen aufzuteilen. Kein Dump, kein Reload, kein benutzerdefiniertes Migrationsskript.

Die logische Replikation setzte ihren stetigen Fortschritt fort. Sequenzwerte synchronisieren sich jetzt zwischen Publishern und Subscribern, Publikationen unterstützen ALL SEQUENCES, es gibt eine ordentliche Fehlerberichterstattung zur Sequenzsynchronisation, und das Verhalten bei der Subscription-Aktualisierung rund um Sequenzen wurde verschärft. Publikationen erhielten außerdem eine EXCEPT-Klausel, sodass man alles außer einer Handvoll Tabellen veröffentlichen kann. Und wal_level = replica kann sich nun bei Bedarf automatisch auf logisch hochstufen, mit einem neuen Parameter effective_wal_level, der anzeigt, was tatsächlich unter der Haube passiert.

Autovacuum erhielt die größte strukturelle Überarbeitung seit Jahren. Parallele Vacuum-Worker sind jetzt für Autovacuum verfügbar, gesteuert durch autovacuum_max_parallel_workers. Ein neues Bewertungssystem bestimmt die Reihenfolge, per Tabelle einstellbar über autovacuum_vacuum_insert_score_weight und autovacuum_vacuum_score_weight, und sichtbar durch eine neue pg_stat_autovacuum_scores-Ansicht. Kerstiens beschrieb REPACK CONCURRENTLY als „eines jener Features, das produktive Postgres-Nutzer mehr interessiert, als der durchschnittliche Release-Note-Leser erwarten würde." Details können sich bis zum GA noch ändern.

Technische Anatomie

Beginnen wir mit REPACK. Das historische Problem ist einfach erklärt: VACUUM FULL schreibt eine Tabelle neu, aber setzt dabei eine ACCESS EXCLUSIVE-Sperre, was bedeutet, dass jede Abfrage, jeder Verbindungspool und jeder nachgelagerte Dienst ins Stocken gerät. pg_repack umging dies, indem eine Schattentabelle erstellt, Änderungen über Trigger nachgespielt und am Ende unter einer kurzen Sperre getauscht wurde. Das funktionierte, aber es war eine Erweiterung, die man installieren, versionieren und über größere Upgrades hinweg vertrauen musste. Das Einbetten dieses Musters in den Core bedeutet, dass die Swap-Logik jetzt von denselben Personen gepflegt wird, die die Speicherschicht pflegen. Weniger Überraschungen beim Upgrade von 19 auf 20.

Partitions-Merge und -Split sind das operative Äquivalent. Bisher bedeutete eine Änderung des Partitionierungsschemas auf der Produktionsebene ein maßgeschneidertes Skript: neue Partitionen erstellen, Zeilen in Batches kopieren, die alten abtrennen und hoffen, dass während des Tauschvorgangs nichts geschrieben wird. Die neue Syntax fasst das in einer einzigen DDL-Anweisung zusammen. Das Beispiel aus der Beta-Dokumentation ist es wert, verinnerlicht zu werden:

ALTER TABLE customer_orders MERGE PARTITIONS (orders_2026_q1, orders_2026_q2) INTO orders_2026_h1;

Und die umgekehrte Aufteilung in orders_2026_07, orders_2026_08, orders_2026_09. Aufbewahrungszeiträume sind keine dauerhaften Architekturentscheidungen mehr.

Die Autovacuum-Änderungen sind subtiler, aber wohl wichtiger. Das Setzen von autovacuum_max_parallel_workers = 4 lässt einen einzelnen Autovacuum-Lauf auf mehrere Worker für dieselbe Tabelle verteilen. Bei einer breiten Tabelle mit mehreren Indizes ist das der Unterschied zwischen einem Vacuum, das vor dem nächsten Schreib-Burst fertig wird, und einem, das es nicht schafft. Das neue Bewertungssystem mit Gewichtungen wie autovacuum_vacuum_insert_score_weight = 3.0 und autovacuum_vacuum_score_weight = 0.5 lässt einem sagen: „Insert-lastige Tabellen sind mir wichtiger als Update-lastige" – oder umgekehrt. pg_stat_autovacuum_scores macht endlich die Warteschlange sichtbar, die Postgres intern bereits berechnete. VACUUM VERBOSE und Autovacuum-Logs enthalten jetzt auch Speicherverbrauch und Parallelismus-Details. Ein separates log_autoanalyze_min_duration ermöglicht das Protokollieren langsamer Analysen, ohne in Vacuum-Spam zu versinken. Die Postgres-Dokumentation enthält die Parameterreferenz, die sich bis zum GA weiterentwickelt.

Wer betroffen ist

Zuerst die Erweiterungsanbieter. pg_repack war sowohl in verwalteten Postgres-Angeboten als auch in selbst gehosteten Setups ein fester Bestandteil. Sobald REPACK im Core stabil ist, schrumpft der Mehrwert der Erweiterung auf „wir unterstützen noch Postgres 13". Das ist ein schrumpfender Markt. Teams, die interne Werkzeuge auf Basis der pg_repack-Trigger gebaut haben, müssen entscheiden, ob sie auf Core REPACK migrieren oder ihren eigenen Fork pflegen wollen.

Dann kommen die Teams, die große partitionierte Tabellen ohne geeignete Werkzeuge betreiben. Wenn die Arbeitslast aus iGaming-Session-Logs, Fintech-Transaktionsbüchern oder AdTech-Impression-Tabellen besteht, gibt es mit hoher Wahrscheinlichkeit ein Partitionierungsschema, das vor zwei Jahren sinnvoll war und es heute nicht mehr ist. Produktionsincidents rund um Partition-Retention lassen sich fast immer auf dieselbe Grundursache zurückführen: Jemand hat sich für monatliche Partitionen entschieden, obwohl wöchentliche besser gewesen wären, und niemand wollte daran rühren, weil die Migration zu riskant war. Postgres 19 nimmt diese Ausrede weg – was bedeutet, dass technische Schulden jetzt sichtbare Schulden sind.

Benutzer logischer Replikation, die am Rand des Sequenzproblems operieren, sind die dritte Gruppe. Wer bisher Blue-Green-Umstellungen durchgeführt hat, bei denen nach der Migration manuell SELECT setval(...) über hundert Sequenzen ausgeführt werden musste, kann dieses Ritual nun endlich automatisieren. Der unbequeme Befund: Mehrere Disaster-Recovery-Runbooks, die ich bei Fintech-Unternehmen gesehen habe, gehen noch immer von manueller Sequenzabstimmung aus. Diese Runbooks sind jetzt falsch, aber niemand wird sie aktualisieren, bis ein Audit dazu zwingt.

Verwaltete Postgres-Anbieter stehen unter einem subtileren Druck. Ihre Differenzierung durch operative Features – benutzerdefiniertes Vacuum-Tuning, proprietäres Bloat-Management – wurde gerade komprimiert. Core Postgres frisst ihr Alleinstellungsmerkmal, eine Version nach der anderen. Das ist gut für Kunden und unangenehm für Preisseiten.

Playbook für Entwicklungsteams

Erstens: Kein Upgrade der Produktion auf eine Beta. Das ist offensichtlich, und ich sage es trotzdem, weil es immer jemanden gibt, der es versucht. Aber diese Woche eine Postgres 19 Beta-Instanz in der Staging-Umgebung aufsetzen und eine repräsentative Arbeitslast dagegen abspielen. Es geht nicht darum, GA-Bereitschaft zu zertifizieren, sondern darum, Verhaltensänderungen frühzeitig zu erkennen – insbesondere rund um das Autovacuum-Scoring.

Zweitens: Die pg_repack-Abhängigkeiten prüfen. Alle Umgebungen auflisten, in denen die Erweiterung installiert ist, jeden Cron-Job, der sie aufruft, jedes Runbook, das sie referenziert. Die Migration zu Core REPACK CONCURRENTLY jetzt entwerfen, auch wenn sie erst 2027 ausgeführt wird. Der Syntax-Wechsel ist klein, der mentale Modell-Wechsel nicht.

Drittens: Die Partitionierungsschemas mit frischen Augen überprüfen. Wer mit ungünstigen Partitionsgrößen gelebt hat, weil die Korrektur zu invasiv war, sollte jetzt ein Ticket für eine Postgres 19 GA-Migration im Backlog anlegen. Unterbelegte Partitionen zusammenführen, überlastete aufteilen.

Viertens: Autovacuum mit parallelen Workern auf den größten Tabellen benchmarken. Konservativ beginnen: autovacuum_max_parallel_workers = 2, I/O-Sättigung beobachten, dann nach oben anpassen. Die Score-Gewichtungen entsprechend der Arbeitslast setzen – ob insert-dominiert oder update-dominiert – und pg_stat_autovacuum_scores nutzen, um zu validieren, ob die Warteschlange der eigenen Intuition entspricht.

Fünftens: Die Runbooks zur logischen Replikation aktualisieren und manuelle Sequenzabstimmungsschritte entfernen, sobald Version 19 im Einsatz ist. Dann die Fehlermodi testen: Was meldet die Sequenzsynchronisations-Fehlerberichterstattung tatsächlich, und greift das eigene Alerting an?

Wichtige Erkenntnisse

• REPACK CONCURRENTLY im Core beendet eine jahrzehntealte Erweiterungsabhängigkeit und beseitigt eine häufige Ursache für nächtliche Wartungsfenster.
• ALTER TABLE ... MERGE PARTITIONS und SPLIT PARTITION machen Partitionierungsschemas ohne maßgeschneiderte Migrationsskripte weiterentwickelbar.
• Parallele Autovacuum-Worker plus das neue Bewertungssystem (mit pg_stat_autovacuum_scores) geben Operatoren erstmals echte Hebel für das Bloat-Management.
• Die logische Replikation behandelt Sequenzsynchronisation endlich korrekt und schließt damit eine bekannte Fehlerquelle bei Migrationen und HA-Setups.
• Beta bedeutet, dass sich Details bis zum GA noch ändern können. Jetzt in der Staging-Umgebung testen, aber Produktions-Runbooks erst nach der finalen Version überarbeiten.