PostgreSQL 18: Async I/O, Skip Scan und Upgrade-Praxis

Warum PostgreSQL 18 mehr ist als Release Notes

Für Teams ist nicht nur relevant, was neu ist. Wenn du die PostgreSQL 18 new features bewertest, starte mit deinen Workloads: Welche Abfragen sind langsam? Welche Wartungsjobs dauern zu lange? Welche Indexe verursachen Schreibkosten? Und welche SQL-Features können Anwendungscode vereinfachen?

Der praktische Nutzen betrifft mehrere Rollen: SQL-Entwickler prüfen neue Ausdrucksmöglichkeiten in DML-Statements, Datenbankadministratoren planen Upgrades und Wartung, Data Analysts messen Reporting-Abfragen, Plattformteams bewerten Authentifizierung und Lifecycle-Prozesse, Anwendungsteams betrachten IDs, Index-Lokalität und Latenz. Aktuelle Entwicklerumfragen wie die Stack Overflow Developer Survey zeigen seit Jahren, dass PostgreSQL zu den meistgenutzten Datenbanken gehört. Für viele Teams sind Major-Upgrades deshalb keine Randaufgabe.

PostgreSQL 18 Async I/O: wo echte Performance-Gewinne möglich sind

PostgreSQL 18 führt ein asynchrones I/O-Subsystem ein. Praktisch bedeutet das: Der Server kann bestimmte Leseoperationen besser überlappen, statt strikt auf einzelne Storage-Zugriffe zu warten. Das PostgreSQL-Projekt nennt für einzelne Benchmarks bis zu dreifache Verbesserungen beim Lesen von Daten vom Speichersystem, unter anderem bei Sequential Scans, Bitmap Heap Scans und Vacuum-Operationen.

Relevant ist das vor allem, wenn dein Engpass wirklich beim Lesen von Daten liegt. CPU-lastige Aggregationen, ungünstige Joins, Lock-Waits oder Netzwerk-Latenzen werden dadurch nicht automatisch schneller. Besonders interessant sind große Tabellen-Scans, Reporting-Abfragen, analytische Batch-Läufe, Vacuum-intensive Umgebungen und Systeme, in denen Storage-Latenz sichtbar ist.

Checkliste für Async-I/O-Tests

• Vergleiche EXPLAIN (ANALYZE, BUFFERS) vor und nach dem Upgrade für repräsentative Lese-Workloads.
• Miss Sequential Scans, Bitmap Heap Scans, Reporting-Jobs und Vacuum-Laufzeiten getrennt.
• Beobachte Storage-Metriken wie Durchsatz, Latenz, Warteschlangen und Cache-Verhalten.
• Trenne Tests mit kaltem Cache von Tests mit warmem Cache, sonst vergleichst du unterschiedliche Effekte.
• Erwarte keine pauschale Beschleunigung jeder Query. Prüfe, ob der Engpass bei I/O, CPU, Locks oder Planung liegt.

Für Data- und Reporting-Teams lohnt sich zusätzlich ein gemeinsamer Blick auf SQL, Datenmodell und Abfragepfade. Wenn du SQL für Analytics, Datenmodellierung und Ergebnisaufbereitung vertiefen willst, findest du im BootCamp Data Analyst – Fokus Python und Power BI einen passenden thematischen Einstieg.

Skip Scan: warum mehrspaltige B-Tree-Indizes nützlicher werden

PostgreSQL Skip Scan ist eine wichtige Optimizer-Verbesserung in PostgreSQL 18. Bisher waren mehrspaltige B-Tree-Indizes besonders stark, wenn Abfragen die führenden Indexspalten einschränkten. Mit Skip Scan kann der Planner solche Indizes in mehr Fällen als Zugriffspfad nutzen, auch wenn frühere Indexspalten keine passende Einschränkung haben, spätere Spalten aber für Filterbedingungen hilfreich sind.

Vereinfacht gesagt: Ein Index auf (tenant_id, created_at) kann für eine Abfrage auf created_at interessanter werden, obwohl tenant_id nicht in der WHERE-Bedingung steht. Der Planner kann über Werte der führenden Spalte springen und gezielt relevante Bereiche späterer Spalten nutzen. Wie gut das funktioniert, hängt stark von Kardinalität, Selektivität, Tabellenstatistiken und Kostenmodell ab.

CREATE INDEX idx_orders_tenant_created ON orders (tenant_id, created_at);

EXPLAIN (ANALYZE, BUFFERS)
SELECT id, tenant_id, created_at, total_amount
FROM orders
WHERE created_at >= now() - interval '7 days';

Wann du Skip Scan testen solltest

• Abfragen filtern selektiv auf spätere Spalten eines mehrspaltigen Index.
• Die führende Indexspalte wird häufig nicht eingeschränkt.
• Die führende Spalte hat eine begrenzte Anzahl unterschiedlicher Werte.
• Du hast bisher zusätzliche Einzelindizes angelegt, nur weil mehrspaltige Indizes nicht genutzt wurden.

Die Warnung bleibt: Lege keine mehrspaltigen Indizes blind an. Prüfe EXPLAIN, reale Laufzeiten, Schreibkosten und Indexgröße. Grundlagen zu Planner, Indizes und SQL-Ausführung findest du in der Schulung PostgreSQL Einführung und SQL Grundlagen. Weitere thematische Angebote findest du unter PostgreSQL Seminare.

SQL-Features für die tägliche Entwicklung

PostgreSQL 18 bringt mehrere Verbesserungen, die direkt in Anwendungscode, Migrationen und Datenpipelines sichtbar werden. Für viele Anwendungen ist PostgreSQL uuidv7 besonders interessant: uuidv7() erzeugt zeitlich sortierbare UUIDs. Das kann dort helfen, wo zufällige UUIDs die Index-Lokalität verschlechtern und häufige Inserts über viele B-Tree-Seiten verteilen.

CREATE TABLE events (
  id uuid PRIMARY KEY DEFAULT uuidv7(),
  payload jsonb NOT NULL,
  created_at timestamptz NOT NULL DEFAULT now()
);

Ebenfalls relevant sind virtuelle Generated Columns. Werte werden beim Lesen berechnet, nicht gespeichert. In PostgreSQL 18 sind virtuelle Generated Columns der Standard; wenn du gespeicherte Werte brauchst, gib STORED explizit an. Virtuelle Spalten eignen sich für ableitbare Werte, die du konsistent in SQL ausdrücken willst, ohne sie redundant abzulegen.

CREATE TABLE invoices (
  net_amount numeric(12,2) NOT NULL,
  tax_rate numeric(5,2) NOT NULL,
  gross_amount numeric(12,2) GENERATED ALWAYS AS (net_amount * (1 + tax_rate)) VIRTUAL
);

OLD- und NEW-Unterstützung in RETURNING-Klauseln macht DML-Statements ausdrucksstärker. Du kannst geänderte Werte direkt vergleichen, ohne zusätzliche SELECTs oder Trigger-Hilfskonstrukte für einfache Fälle.

UPDATE products
SET price = price * 1.10
WHERE category = 'hardware'
RETURNING id, old.price AS old_price, new.price AS new_price;

Diese Features eignen sich für klareren Anwendungscode, einfache Audit-ähnliche Workflows und stabile SQL-Schnittstellen zwischen Datenbank und Anwendung. Für breitere Grundlagen zu relationalen Modellen, SQL und Datenbankzugriff lohnt sich ein Blick auf Datenbank Schulungen.

PostgreSQL-18-Upgrade: was du vor dem Wechsel prüfen solltest

Ein PostgreSQL-18-Upgrade ist ein Major-Version-Upgrade, wenn du von PostgreSQL 17 oder älter kommst. Für ein solches PostgreSQL 18 upgrade brauchst du weiterhin einen klaren Migrationspfad: Dump und Restore, pg_upgrade oder logische Replikation. Minor-Updates innerhalb der 18er-Reihe sind davon zu unterscheiden: Sie erfordern in der Regel kein Dump/Restore und kein pg_upgrade, sondern ein Update der Serverpakete und meist einen Neustart. Prüfe vor jedem Wechsel die aktuellen Release Notes und die Hinweise deiner Paketquelle.

• Teste mit produktionsnahen Datenmengen, nicht nur mit kleinen Dumps.
• Dokumentiere Rollback-Pfade inklusive DNS, Verbindungsstrings und Replikationsstatus.
• Vergleiche Batch-Jobs, API-Endpunkte, Reporting-Abfragen und Wartungsaufgaben.
• Plane Statistik-, ANALYZE- und Vacuum-Verhalten nach dem Wechsel ein.

Wenn dein Team Datenbank-Lifecycle, Provisionierung, Patch-Prozesse und Automatisierung strukturierter betrachten will, passt die Schulung Nutanix Database Management and Automation (NDMA) thematisch in den operativen Kontext.

pg_upgrade und Planner-Statistiken: warum Upgrades ruhiger laufen können

Eine praktische Verbesserung in PostgreSQL 18 ist, dass pg_upgrade Optimizer-Statistiken übernehmen kann. Das kann die Phase nach dem Upgrade entschärfen, weil der Planner nicht vollständig ohne vertraute Statistikinformationen starten muss. Gerade bei großen Datenbanken kann das Planinstabilität und unmittelbaren Analyse-Druck reduzieren.

Trotzdem solltest du kritische Queries validieren. Vergleiche Baselines für Reporting, nächtliche Batch-Prozesse, API-Abfragen mit niedriger Latenztoleranz und Maintenance Tasks wie Vacuum oder Index-Rebuilds. Ein glatter technischer Upgrade-Lauf ersetzt keine fachliche Performance-Abnahme.

OAuth in PostgreSQL 18: was es kann und was nicht

PostgreSQL 18 unterstützt OAuth-2.0-Authentifizierung mit Bearer-Tokens. Das ist für Teams interessant, die Datenbankzugriffe stärker an moderne Identity- und Access-Patterns anbinden wollen. Wichtig ist die Grenze: PostgreSQL stellt nicht selbst den Authorization Server bereit. Du brauchst weiterhin einen OAuth-Provider, der Tokens ausstellt, prüfbare Claims liefert und in deine organisatorischen Prozesse eingebunden ist.

Bewerte OAuth deshalb als Baustein in einer größeren Sicherheitsarchitektur, nicht als vollständige Identity-Management-Lösung. Prüfe Token-Lebensdauer, Rollenmapping, Service-Accounts, Notfallzugänge und Audit-Anforderungen gemeinsam mit deinem Plattform- und Security-Team.

Praktische Reihenfolge: was du zuerst testen solltest

1. Benchmarke leselastige Workloads, die von Async I/O profitieren könnten.
2. Prüfe mehrspaltige Indizes und Abfragen, bei denen Skip Scan neue Planoptionen eröffnet.
3. Teste uuidv7(), wenn sortierbare IDs deiner Anwendung oder Indexstrategie helfen.
4. Bewerte virtuelle Generated Columns und RETURNING old/new in Entwicklungs- und Migrationsskripten.
5. Führe eine Upgrade-Generalprobe mit produktionsnahen Daten, Extensions, Backups und repräsentativen Queries durch.

PostgreSQL 18 lohnt sich besonders dann, wenn du nicht nur aktualisierst, sondern gezielt misst. Die wichtigsten Gewinne entstehen aus der Kombination: bessere I/O-Nutzung, ein flexiblerer Planner, ausdrucksstärkeres SQL und sorgfältiger Betrieb. Genau dort solltest du deine Tests beginnen.