PostgreSQL 19 RC1: JIT aus, LZ4 für TOAST, GA am 19. November

Am 15. Oktober 2026 hat die PostgreSQL-Entwicklergruppe den ersten Release Candidate von PostgreSQL 19 veröffentlicht. Die finale Version ist für den 19. November geplant, ein zweiter Kandidat für den 12. November. Die Ankündigung nennt Fehlerkorrekturen seit Beta 4 und einige Verhaltensänderungen. Was sich für Betreiber ändert, steht in den Release Notes zu 19.

Standardwerte, die sich ändern

In den Release Notes steht unter den Inkompatibilitäten, dass JIT standardmäßig abgeschaltet ist. Wörtlich heißt es dort, Betriebe mit vielen großen analytischen Abfragen müssten JIT nun von Hand einschalten. Wer bisher mit dem Standard lebte, merkt die Änderung vor allem bei Berichtsabfragen, die vorher von der Kompilierung profitierten. Ob das bei der eigenen Last der Fall ist, zeigt ein Vergleich derselben Abfragen mit jit = on und jit = off auf einer Testkopie.

Die zweite Änderung betrifft default_toast_compression. Der Standard wechselt von pglz auf lz4. Nach unserer Lesart gilt das für neu geschriebene große Werte, bereits gespeicherte Daten wandelt der neue Standard nicht von selbst um. Messen lässt sich der Effekt an Tabellen mit großen Text-, JSON- oder Bytea-Spalten, über Tabellengröße und CPU-Last beim Schreiben.

Dazu kommen zwei kleinere Zahlen aus derselben Liste. max_locks_per_transaction steigt von 64 auf 128, und standard_conforming_strings ist fest auf on. Dumps, die mit standard_conforming_strings = off erzeugt wurden, lassen sich unter Umständen nicht mehr einspielen.

Was pg_upgrade ablehnt

Für den Weg von einer älteren Version nennen die Release Notes drei Möglichkeiten: Dump und Restore mit pg_dumpall, pg_upgrade oder logische Replikation. Bei pg_upgrade gibt es zwei neue Sperren:

• Cluster mit btree_gist-Indizes auf inet oder cidr werden abgelehnt, weil diese Operatorklassen Zeilen ausschließen können, die zurückkommen müssten.
• Cluster mit Zeilenumbruch (CR oder LF) in Datenbank-, Rollen- und Tablespace-Namen werden abgelehnt, aus Sicherheitsgründen.

Neu ist außerdem, dass pg_upgrade Tablespaces im Datenverzeichnis verarbeitet und das Kopieren von Large-Object-Metadaten schneller läuft.

Neues, das einen Test lohnt

REPACK ersetzt VACUUM FULL und CLUSTER, die alten Befehle bleiben. Mit der Option CONCURRENTLY baut es Tabellen ohne exklusive Sperre um, dazu gibt es die Einstellung max_repack_replication_slots. Für Tabellen, die man bisher nur im Wartungsfenster aufräumen konnte, ist das der interessanteste Punkt. Die RC-Meldung führt mehrere Korrekturen genau dafür auf, es ist also noch jung.

Das Modul pg_plan_advice soll Planerentscheidungen stabilisieren und steuerbar machen, pg_stash_advice hängt Hinweise an einzelne Query-IDs. Und logische Replikation lässt sich bei wal_level = replica ohne Neustart aktivieren; der effektive Wert zeigt die neue Variable effective_wal_level.

Was wir damit machen

Unsere Postgres-Instanzen laufen auf Version 17, darunter der gemeinsame Datenbankserver und die Datenbank hinter unseren Mailgateways. Ein Release Candidate gehört nicht in die Produktion. Die Wartezeit bis zum 19. November lässt sich aber nutzen: Cluster kopieren, pg_upgrade gegen die Kopie laufen lassen, dann die wichtigsten Abfragen mit beiden JIT-Einstellungen messen. Die Zahl, die man am Ende haben will, ist die eigene.

heise ordnet den RC in seiner Entwicklerübersicht nur knapp ein und nennt als finales Erscheinungsdatum ebenfalls den 19. November. Die Details zu JIT und LZ4 stehen dort nicht, sie kommen ausschließlich aus den Release Notes des Projekts.

Weiterführende Quellen

• PostgreSQL 19 RC 1 Released (15.10.2026)
• PostgreSQL 19 Release Notes
• heise developer: Was Postgres 19, Python 3.16 und Symfony 8.2 Neues bringen (17.10.2026)
• Simple Icons: postgresql.svg (Logo, CC0)