PostgreSQL 18: Async-I/O, uuidv7, Generated Columns und warum Entwickler das kennen sollten

PostgreSQL macht weiterhin das, was in der Softwarewelt selten ist: Es wird jedes Jahr besser, ohne schlechter zu werden. Version 18 ist ein gehaltvolles Release, und ungewöhnlich für ein Datenbank-Upgrade sind mehrere der wichtigsten Neuerungen Dinge, die Anwendungsentwickler: nicht nur DBAs: tatsächlich spüren werden. Ein neues asynchrones I/O-Subsystem, ein eingebauter Generator für zeitlich geordnete UUIDs, flexiblere generierte Spalten und intelligentere Indizierung adressieren jeweils echte, alltägliche Probleme. Dieser Leitfaden führt durch die Änderungen, die für diejenigen relevant sind, die die Abfragen schreiben, und warum sich ein Upgrade lohnt.

Asynchrones I/O: schnellere Lesevorgänge unter Last

Bisher führte PostgreSQL Festplattenlesevorgänge einzeln aus und wartete auf jeden einzelnen: bei schnellem Speicher mit kleinen Working Sets in Ordnung, weniger jedoch, wenn eine Abfrage viele Seiten abrufen muss, die nicht im Cache liegen. Version 18 führt ein asynchrones I/O-Subsystem ein, das es der Datenbank erlaubt, mehrere Leseanfragen gleichzeitig zu stellen, sodass sie weniger Zeit mit Warten auf den Speicher verbringt. Für leseintensive Workloads, große Scans und analytische Abfragen kann dies den Durchsatz spürbar verbessern, insbesondere wenn die Daten nicht vollständig in den Arbeitsspeicher passen.

uuidv7(): der richtige Weg für UUID-Schlüssel

Entwickler lieben UUIDs als Primärschlüssel: global eindeutig, clientseitig generierbar, keine zentrale Sequenz. Aber herkömmliche zufällige UUIDs (v4) haben einen unangenehmen Nebeneffekt: Da sie zufällig sind, verteilt das Einfügen die Schreibvorgänge über den gesamten Index, was mit wachsenden Tabellen zu Fragmentierung und schlechtem Cache-Verhalten führt. UUIDv7 behebt dies, indem es einen Zeitstempel einbettet, sodass die Werte zeitlich geordnet sind: Neue Zeilen gruppieren sich im Index ähnlich wie bei automatisch inkrementierenden Ganzzahlen, während die UUID-Eindeutigkeit erhalten bleibt. PostgreSQL 18 fügt eine eingebaute Funktion hinzu, sodass Sie keine Erweiterung oder clientseitige Bibliothek mehr benötigen, um sie zu erhalten.uuidv7() Funktion, sodass Sie keine Erweiterung oder clientseitige Bibliothek mehr benötigen, um sie zu erhalten.

-- Time-ordered UUID keys, built in — unique AND index-friendly.
CREATE TABLE orders (
    id          uuid PRIMARY KEY DEFAULT uuidv7(),
    customer_id bigint NOT NULL,
    created_at  timestamptz NOT NULL DEFAULT now()
);

-- New rows cluster at the "end" of the index like serial ids,
-- avoiding the write scattering that random uuidv4 causes.

Generierte Spalten werden flexibler

Generierte Spalten lassen die Datenbank eine Spalte automatisch aus anderen Spalten berechnen. Bisher unterstützte PostgreSQL nur gespeicherte generierte Spalten: der Wert wird beim Schreiben berechnet und auf der Festplatte gespeichert. Version 18 führt virtuelle generierte Spalten ein, die bei Bedarf beim Lesen berechnet werden, sodass sie keinen Speicherplatz kosten und nie veralten. Das ist ideal für abgeleitete Werte, die Sie wie eine normale Spalte abfragen möchten, aber nicht physisch persistieren wollen.

CREATE TABLE products (
    price_cents   int  NOT NULL,
    tax_rate      numeric NOT NULL,
    -- computed on read: no storage, always current with its inputs
    total_cents   int GENERATED ALWAYS AS
                  (price_cents + round(price_cents * tax_rate)) VIRTUAL
);

Skip Scan: mehr Abfragen nutzen Ihre Indizes

Ein klassischer Fallstrick: Sie haben einen mehrspaltigen Index auf (a, b), aber eine Abfrage filtert nur nach b, sodass PostgreSQL den Index nicht effizient nutzen kann und auf einen langsameren Scan zurückfällt. Version 18 verbessert dies mit Skip Scan, der es dem Planer erlaubt, einen solchen Index auch dann zu verwenden, wenn die führende Spalte nicht eingeschränkt ist, indem er effektiv durch deren unterschiedliche Werte „springt“. Der praktische Effekt ist, dass mehr Ihrer bestehenden Abfragen auf bereits vorhandene Indizes zurückgreifen können, ohne dass Sie neue hinzufügen müssen.

Ein reibungsloserer Upgrade-Pfad

Große PostgreSQL-Upgrades hatten lange einen versteckten Preis: Nach dem Upgrade wurden die Statistiken des Abfrageplaners nicht übernommen, sodass das frisch aktualisierte System mit schlechten Plänen arbeiten konnte, bis diese Statistiken neu aufgebaut waren: manchmal ein unangenehmer Leistungseinbruch genau dann, wenn man ihn am wenigsten gebrauchen kann. Version 18 verbessert diesen Bereich, sodass Upgrades seltener zu einer vorübergehend langsamen Datenbank führen und das Risiko sowie den Stress eines Major-Versionswechsels verringern.

Sollten Sie upgraden?