PostgreSQL 18: fünf Änderungen, die sich auf Ihrer Datenbank testen lassen

PostgreSQL 18 erschien am 25. September 2025. Die Release Notes umfassen mehrere unabhängige Richtungen: asynchrones I/O für ausgewählte Read- und Vacuum-Operationen, B-tree Skip Scan, zeitlich geordnetes uuidv7(), virtuelle Generated Columns, OAuth-Unterstützung und zeitliche Constraints. [1] Das ist keine einzelne große Funktion mit Checkbox. Es ist ein Bündel von Möglichkeiten, die jeweils gegen Schema, Query-Pläne und Betriebsumgebung geprüft werden müssen.

Die schlechteste Bewertung wäre: ‚Postgres 18 ist dreimal schneller.‘ Das PostgreSQL Project berichtet über bis zu 3× Verbesserung in bestimmten Storage-Read-Szenarien; dieses Ergebnis gehört aber zu konkreten I/O-Bedingungen. [2] Eine Abfrage, die an CPU, Locks, Netzwerk, einem schlechten Index oder einem langsamen Upstream hängt, ändert sich nicht automatisch.

Ein besserer Upgrade-Grund ist ein konkreter Schmerz, den der Release berühren kann: große Scans und Vacuum-Arbeit, zufällige UUID-Primary-Keys auf einer Tabelle mit aktiven Inserts, Abfragen über eine nicht führende Spalte eines mehrspaltigen B-tree oder die Anbindung von Clients über einen Unternehmens-OAuth-Flow.

Jede Fähigkeit unten hat einen klaren Test. Fehlt dieser Test, sollte sie nicht der Hauptgrund für ein Upgrade sein.

UUIDv4 ist als verteilter Identifier nützlich, doch seine zufällige Reihenfolge verteilt neue Einträge über den gesamten B-tree. uuidv7() enthält eine Zeitkomponente, sodass neue Werte überwiegend in eine Richtung laufen. PostgreSQL 18 liefert die Funktion im Core. [1] Für neue externe Identifier ist das oft ein besserer Default als ein selbst erzeugtes UUIDv7 oder eine zusätzliche Extension.

‚Überwiegend‘ ist wichtig. UUIDv7 garantiert keine absolute Reihenfolge bei jedem parallelen Write, löst keine Contention auf einem heißen Index und ersetzt kein sinnvolles Partitioning. Es liefert einen Schlüssel, dessen Zeitordnung besser zur Insert-Reihenfolge passt. Der Gewinn gehört in den realen Write-Path-Metriken gesucht, nicht in der Form der ID.

Für ein bestehendes System ist ein Hybrid oft ruhiger: historische UUIDs bleiben, neue Tabellen oder Entitäten verwenden UUIDv7. Ein Austausch von Primary Keys im großen Maßstab berührt Foreign Keys, Caches, API-Verträge, Replikation und Backup-Prozesse. Ein Datenbank-Release allein ist kein Grund, dieses Risiko einzugehen.

PostgreSQL nennt drei Hauptwege zwischen Major-Versionen: Dump/Restore, pg_upgrade oder logical replication. [1] Die Wahl hängt von akzeptabler Downtime, Datenmenge und Rollback-Anforderungen ab.

PostgreSQL 18 ergänzt OAuth-Support, und libpq implementiert einen optionalen Device-Authorization-Client-Flow. [3] Das ist nützlich, wenn Datenbankzugriff über Unternehmensidentität, Scopes und kurzlebige Tokens laufen soll. Nicht jeder Treiber und jeder Verbindungsweg unterstützt dies sofort; ein Kompatibilitätstest ist daher Pflicht.

Gleichzeitig setzt der Release die Bewegung weg von md5 Password Authentication fort; MD5-Unterstützung soll in einer zukünftigen Major-Version entfernt werden. [1] Das ist ein guter Zeitpunkt zu prüfen, ob alle Clients SCRAM unterstützen, wo Credentials liegen, wie Zugriffe rotiert werden und welche Service-Accounts noch übliche Regeln umgehen.

PostgreSQL 18 liefert genug Gründe, ein Upgrade auf die Roadmap zu setzen. Der stärkste ist je nach System anders: I/O und Maintenance hier, UUIDv7 für neue write-lastige Tabellen dort, mehrspaltige Indizes oder OAuth an anderer Stelle. Keiner dieser Gründe ersetzt Staging und Baseline.

Nach einem Pilot sollte das Ergebnis konkret sein: Upgrade, weil kritische Scans günstiger wurden; UUIDv7 nur für neue Tabellen; bestehende Indizes behalten; OAuth bis zur Treiberreife verschieben. Diese Entscheidungsliste ist nützlicher als die pauschale Aussage, eine neue Version sei ‚schneller‘.