PostgreSQL 19 Beta 3 landet in der RDS-Vorschau

Beta 3 tritt aus dem Testlabor der Community

Seit heute steht PostgreSQL 19 Beta 3 in der Amazon RDS Database Preview Environment bereit. Wer testen will, wie sich die kommende Hauptversion unter RDS-Bedingungen verhält, kann das laut der AWS-Ankündigung zur Preview-Umgebung ab sofort in einer isolierten Umgebung tun, ohne produktive Instanzen zu berühren.

Inhaltlich bringt Beta 3 vor allem zwei Baustellen voran: Abfrageleistung und Autovacuum-Verwaltung. Beides sind Dauerthemen im Betrieb größerer PostgreSQL-Installationen, und beide Themenfelder wurden in dieser Beta konkret erweitert statt nur kosmetisch nachgezogen. Wer PostgreSQL im Serverbetrieb einsetzt, kennt den Unterschied zwischen einem Release, das nur ein Versionsschild wechselt, und einem, das tatsächlich an den Stellen ansetzt, an denen es im Alltag klemmt.

Daneben bringt Beta 3 laut Ankündigung Bugfixes und Stabilitätsverbesserungen aus der Beta-2-Testphase mit. Das ist der unspektakuläre, aber wichtige Teil jeder Beta-Iteration: Fehler, die in der vorherigen Runde von der Community gemeldet wurden, fließen zurück in den Code, bevor die nächste Testrunde beginnt. Für PostgreSQL 19 Beta 3 heißt das konkret, dass Sie nicht bei Null anfangen, sondern auf einer bereits einmal durchgetesteten Basis aufsetzen. Für einen Wartbarkeits-Check lohnt sich trotzdem der Blick ins offizielle PostgreSQL-Release-Changelog, weil AWS in der eigenen Ankündigung naturgemäß nur einen Ausschnitt der Änderungen nennt.

Wichtig für die Lizenzfrage bleibt: An der PostgreSQL-Lizenz selbst ändert sich durch die RDS-Integration nichts. PostgreSQL bleibt unter seiner eigenen, BSD-ähnlichen Lizenz frei nutzbar; RDS ist lediglich der verwaltete Betrieb obendrauf. Wer PostgreSQL 19 Beta 3 also parallel auf eigener Infrastruktur testen will, unterliegt keinen zusätzlichen Einschränkungen durch die AWS-Vorschau.

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellseedream_v4_5; quality=high; 5120x2880PromptA maintainer hand moves a duplicate ceramic data row through a separate preview channel beside an untouched production archive of stacked glass plates. A tight documentary composition emphasizes hands-on consequences in a fully text-free scene with blank surfaces and no legible markings. Photorealistic style image. Mood: practical, focused, and investigative. Avoid: watermark, signature, blurry, low quality, distorted, deformed, readable text, labels, numbers, captions, UI, dashboards, screens.

Die RDS-Preview-Umgebung als isolierter Sandkasten

Wichtig für die Einordnung: Die RDS Database Preview Environment ist kein Vorgeschmack auf ein reguläres RDS-Feature, sondern ein eigener, klar abgegrenzter Bereich. Instanzen dort werden laut AWS nach maximal 60 Tagen automatisch gelöscht. Wer PostgreSQL 19 Beta 3 also über einen längeren Testzeitraum begleiten will, muss diese Frist von vornherein in die eigene Testplanung einbauen und darf keine dauerhaften Abhängigkeiten in dieser Umgebung aufbauen.

Eine zweite Einschränkung betrifft Snapshots: Datenbank-Snapshots, die in der Preview-Umgebung erstellt werden, lassen sich laut AWS ausschließlich innerhalb dieser Preview-Umgebung wieder zum Anlegen oder Wiederherstellen von Instanzen nutzen. Ein Snapshot aus der Preview-Umgebung wandert also nicht einfach in Ihre produktive RDS-Landschaft zurück. Das ist konsequent, sorgt aber dafür, dass jeder Testlauf mit PostgreSQL 19 Beta 3 organisatorisch getrennt bleibt von dem, was Sie tatsächlich produktiv betreiben.

Für die Praxis bedeutet das: Sie bauen sich am besten ein Testszenario mit synthetischen oder anonymisierten Daten auf, das Sie innerhalb der 60-Tage-Frist mehrfach durchlaufen können, statt eine einzelne Preview-Instanz als dauerhaften Testserver misszuverstehen. Ein sauberes Skript, das Schema, Testdaten und Konfiguration reproduzierbar aufsetzt, ist hier mehr wert als eine manuell gepflegte Einzelinstanz, die nach 60 Tagen ohnehin verschwindet.

Wer in seinem Team ohnehin mit Infrastructure-as-Code arbeitet, kann diese Vergänglichkeit sogar als Vorteil nutzen: Ein Terraform- oder CloudFormation-Stack, der die Preview-Instanz samt Testdaten aus einem Dump neu aufbaut, lässt sich beliebig oft innerhalb der Frist neu ausrollen und liefert bei jedem Lauf denselben Ausgangszustand für den Vergleich mit PostgreSQL 19 Beta 3.

Autovacuum bekommt endlich eine Priorisierungs-Übersicht

Der aus Betriebssicht interessanteste Einzelbaustein ist die neue View pg_stat_autovacuum_scores. Sie erlaubt es laut AWS, die Priorisierung von Autovacuum-Läufen zu beobachten und gezielt nachzujustieren. Wer schon einmal versucht hat, aus den Bordmitteln von PostgreSQL herauszulesen, warum Autovacuum ausgerechnet Tabelle A vor Tabelle B abarbeitet, kennt das Problem: Bislang musste man das aus Nebeneffekten und Logeinträgen rekonstruieren.

Mit einer dedizierten View wird dieser Priorisierungsmechanismus erstmals direkt abfragbar. Das klingt nach einem kleinen Detail, spart aber im Alltag echte Diagnosezeit, wenn Autovacuum auf einer stark beschriebenen Tabelle nicht hinterherkommt und Sie schnell wissen müssen, ob das an der Priorisierung liegt oder an etwas anderem. Für Teams, die PostgreSQL 19 Beta 3 gezielt auf Wartungsverhalten hin testen, ist das der naheliegende erste Anlaufpunkt.

Interessant ist außerdem, dass Eager Aggregation als weitere Optimierung analytische Abfragen beschleunigt, indem Daten früher im Abfrageplan gruppiert werden, sodass am Ende weniger Zeilen verarbeitet werden müssen. Das zahlt nicht direkt auf die Wartungsseite ein, zeigt aber, dass der Query-Planer in dieser Version an mehreren Fronten gleichzeitig nachgeschärft wurde.

Aus Monitoring-Sicht lohnt sich der Blick auf pg_stat_autovacuum_scores schon deshalb, weil sich damit Alarmierungen deutlich präziser bauen lassen: Statt pauschal zu melden, dass Autovacuum auf einer Tabelle ‚lange läuft‘, kann ein Dashboard künftig zeigen, ob eine Tabelle überhaupt priorisiert wurde oder in der Warteschlange hinten liegt. Wer eigene Grafana- oder Zabbix-Checks pflegt, sollte diese View frühzeitig in der Preview-Umgebung gegen bestehende Metriken abgleichen.

Parallele Wartung für große Tabellen

Der zweite große Autovacuum-Baustein ist Parallelität: Paralleles Autovacuum kann laut AWS nun mehrere Worker gleichzeitig einsetzen, um die Wartung großer Tabellen zu beschleunigen. Bisher lief Autovacuum je Tabelle im Wesentlichen sequenziell, was auf sehr großen, stark fragmentierten Tabellen zu Wartungsfenstern führen konnte, die sich über Stunden zogen.

Für Sie als Betreiber heißt das konkret: Wenn Ihre größten Tabellen bislang der limitierende Faktor bei Autovacuum-Laufzeiten waren, lohnt es sich, genau diese Tabellen in der Preview-Umgebung unter realistischer Last nachzustellen und die Laufzeitverbesserung selbst zu messen, statt sich auf die Ankündigung allein zu verlassen. Parallelität bringt in der Praxis fast immer zusätzliche Fragen zur Ressourcenverteilung mit sich, etwa wie viele Worker sinnvoll parallel laufen dürfen, ohne dass reguläre Abfragen währenddessen leiden.

Auf RDS-Instanzen ist dabei die vCPU- und I/O-Ausstattung der jeweiligen Instanzklasse der begrenzende Faktor: Mehr parallele Autovacuum-Worker helfen nur, solange genug Rechenleistung und Durchsatz zur Verfügung stehen, um sie gleichzeitig zu bedienen. Ein Test auf einer kleinen Preview-Instanzklasse sagt deshalb wenig darüber aus, wie sich das Feature auf Ihrer tatsächlichen Produktionsklasse verhält; für belastbare Zahlen sollten Sie eine vergleichbare Instanzgröße wählen.

Planstabilität statt Überraschungen im Optimizer

Ein weiteres neues Modul, pg_plan_advice, adressiert ein Problem, das viele PostgreSQL-Betreiber aus schmerzhafter Erfahrung kennen: Der Query-Planer wählt nach einem Statistik-Update, einem Upgrade oder schlicht mit wachsendem Datenvolumen plötzlich einen anderen, deutlich schlechteren Ausführungsplan für eine bislang unauffällige Abfrage. Laut AWS lässt sich mit dem Modul ein einmal als effizient erkannter Plan festschreiben, um genau solche unerwarteten Verlangsamungen zu vermeiden.

Das ist aus Wartbarkeitssicht ein sinnvoller Schritt, weil es die Lücke zwischen ‚der Planer hat theoretisch recht‘ und ‚der Planer sorgt gerade für einen Produktionsvorfall‘ schließt. Wer kritische, latenzsensitive Abfragen betreibt, bekommt damit ein Werkzeug, um Planänderungen kontrolliert zuzulassen statt sie ungeprüft durchzureichen. Bevor Sie sich darauf verlassen, sollten Sie aber in der Preview-Umgebung testen, wie sich festgeschriebene Pläne verhalten, wenn sich die zugrunde liegenden Daten strukturell verändern, etwa nach einem großen Bulk-Import.

Ähnliche Ansätze gibt es in anderen Datenbanksystemen bereits als Plan-Baselines oder Query-Hints, meist als kommerzielle Zusatzfunktion. Dass PostgreSQL mit pg_plan_advice einen vergleichbaren Mechanismus offen in den Kern integriert, passt zur bekannten Linie des Projekts, Betriebswerkzeuge nicht hinter Lizenzgrenzen zu verstecken. Wer bislang aus genau diesem Grund auf ein anderes System ausgewichen ist, sollte pg_plan_advice als Argument für einen erneuten Blick auf PostgreSQL werten, sofern sich die Funktion in der Preview-Umgebung als robust erweist.

Daten rein, Daten raus: Dump, Load und die Preisfrage

Für den Datentransport in und aus der Preview-Umgebung verweist AWS auf die reguläre PostgreSQL-Dump- und Load-Funktionalität, mit der sich Datenbanken importieren oder exportieren lassen. Das ist erfreulich unspektakulär: Sie brauchen kein Spezialwerkzeug, sondern arbeiten mit denselben Bordmitteln, die Sie ohnehin für Migrationen und Backups kennen. Für einen realistischen Test von PostgreSQL 19 Beta 3 bedeutet das, dass sich ein repräsentativer Datenbestand relativ unkompliziert in die Preview-Umgebung überführen lässt.

Nicht zu übersehen ist die Preisfrage: Instanzen der Amazon RDS Database Preview Environment werden laut AWS nach der Preisliste der Region US East (Ohio) abgerechnet, unabhängig davon, in welcher Region Sie sonst produktiv unterwegs sind. Wer bereits mit AWS-Bedrock-Workloads experimentiert und dort auf Latenz und Kosten schaut, wie es unsere Auswertung zur Latenzreduktion bei AWS-Bedrock-Agenten beschreibt, kennt das Prinzip: Auch Testumgebungen verursachen reale Kosten, und die Preisregion der Testumgebung muss nicht die Preisregion Ihres Produktivsystems sein.

Für die Kostenkontrolle heißt das praktisch: Bevor Sie eine größere Preview-Instanz für einen Lasttest hochziehen, lohnt sich ein kurzer Abgleich mit dem aktuellen Preisblatt für US East (Ohio), weil Instanzklassen dort abweichend von Ihrer Heimatregion bepreist sein können. Wer die Preview-Umgebung nur für funktionale Tests nutzt, kommt in der Regel mit kleinen Instanzklassen aus und hält die Rechnung entsprechend niedrig.

Was für den produktiven Umstieg noch fehlt

Zusammengenommen zeigt PostgreSQL 19 Beta 3 in der RDS-Vorschau ein Muster, das sich bei AWS in den vergangenen Monaten wiederholt: Neue Fähigkeiten werden zuerst in einer zeitlich und funktional begrenzten Umgebung angeboten, bevor sie in den regulären RDS-Betrieb wandern. Ähnlich verfährt AWS derzeit mit anderen Vorschau-Angeboten im eigenen Portfolio, etwa wenn zusätzliche Modell-Regionen für Bedrock zunächst schrittweise freigeschaltet werden, wie es auch unser Überblick zu den aktuellen GPT-5.6-Entwicklerneuigkeiten von OpenAI für den KI-Bereich zeigt.

Für Sie als Betreiber bleibt die eigentliche Arbeit trotzdem dieselbe wie bei jeder Beta: Autovacuum-Verhalten, Query-Pläne und Parallelitätsgrenzen unter eigener, realistischer Last nachstellen, statt sich auf die Ankündigung zu verlassen. Erst wenn pg_stat_autovacuum_scores, paralleles Autovacuum und pg_plan_advice in Ihrem eigenen Lastprofil stabile Ergebnisse liefern, ist ein späterer Umstieg auf PostgreSQL 19 überhaupt eine seriöse Option. Bis dahin bleibt die 60-Tage-Frist der Preview-Umgebung der praktische Rahmen, in dem sich das seriös überprüfen lässt.

Ein letzter, oft unterschätzter Punkt: Auch Erweiterungen und Extensions, die Sie produktiv nutzen, sollten Sie in der Preview-Umgebung mittesten, sofern RDS sie für PostgreSQL 19 bereits unterstützt. Erfahrungsgemäß sind es selten die Kernfunktionen einer neuen Major-Version, die beim Upgrade Probleme machen, sondern Erweiterungen von Drittanbietern, die der neuen Version erst mit Verzögerung folgen. Wer das frühzeitig prüft, vermeidet die unangenehme Überraschung, dass der eigentliche Umstieg an einer einzelnen, scheinbar nebensächlichen Extension scheitert.