PostgreSQL 18 Skip Scan bringt 21-fache Beschleunigung auf Aurora

Wer schon einmal um 3 Uhr nachts angerufen wurde, weil ein zusammengesetzter Index nicht mehr zum WHERE-Klauselmuster passte, kennt dieses Problem. PostgreSQL 18 hat eine repräsentative Abfrage auf derselben Hardware von 73,2 ms auf 3,4 ms reduziert – eine 21-fache Verbesserung, ohne einen einzigen neuen Index hinzuzufügen. Das ist die Schlagzahl aus AWS dieser Woche, und sie verändert die Kalkulation für viele Teams beim Entwurf ihrer B-Tree-Layouts.

Die Zahlen

Das Setup ist auf die beste mögliche Art unspektakulär – was es glaubwürdig macht. Wie Amazon Web Services (AWS) berichtete, lief der Benchmark auf einer db.r6g.large-Instanz, einem bescheidenen ARM-Rechner, den viele Teams in Staging- und kleinen Produktionsumgebungen einsetzen. Die Tabelle enthielt eine Million Zeilen in einem customer_orders-Schema mit einem zusammengesetzten Index auf (status, created_date). Die Spalte status hatte genau 5 verschiedene Werte. Beide Durchläufe nutzten einen warmen Buffer-Cache – das ist also kein I/O-Trick.

Auf Aurora PostgreSQL 17.10 tat der Planer das, was er immer getan hat, wenn die führende Spalte in der WHERE-Klausel fehlt: Er fiel auf einen Parallel Seq Scan mit 2 geplanten und 2 gestarteten Workern zurück. Er las 7.353 gemeinsame Blöcke. Jede Worker-Schleife filterte 332.433 Zeilen heraus. Die Planungszeit betrug 0,091 ms, die Ausführungszeit 73,200 ms.

Auf Aurora PostgreSQL 18.4, gleiche Instanz, gleiche Daten, gleiche Abfrage mit dem Filter created_date = '2026-03-15', wechselte der Planer zu einem Bitmap Index Scan auf dem zusammengesetzten Index. Er führte 11 Index-Suchen durch – eine pro unterschiedlichem führenden Wert plus Overhead – und las 2.266 gemeinsame Blöcke. Planungszeit: 0,065 ms. Ausführungszeit: 3,374 ms.

Die Blockanzahl sank also um etwa 69 %. Die Ausführungszeit sank um etwa 95 %. Das ist der 21-fache Wert, und er ist die Art von Zahl, die eine Migration allein rechtfertigt.

Man denke nur daran, was das im operativen Budget bedeutet. Eine Abfrage, die 500 Mal pro Sekunde auf einem stark frequentierten Checkout-Pfad ausgelöst wird, gibt etwa 35 Sekunden CPU-Zeit pro Wanduhr-Sekunde über die gesamte Flotte zurück. Bei einem heißen iGaming-Settlement-Service ist das der Unterschied zwischen dem Bedarf nach einem größeren Writer und keinem. Ich habe Produktionsvorfälle erlebt, bei denen Teams zu früh geshardet haben, weil eine einzelne Planer-Einschränkung wie diese strukturell wirkte. Das war sie nicht. Es war nur eine Version entfernt.

Meine Einschätzung: Das Detail mit den 5 verschiedenen Werten ist das Entscheidende. Skip Scan gewinnt stark, wenn führende Spalten eine niedrige Kardinalität haben. Mit steigender Kardinalität werden aus 11 Index-Suchen 11.000, und die Rechnung ändert sich.

Was wirklich neu ist

Die vier Punkte in Teil 1 der AWS-Serie sind: Skip-Scan-Optimierung für mehrspaltige B-Tree-Indexes, erweiterter EXPLAIN-Output, der das Speicherverhalten offenlegt, automatisches Entfernen unnötiger Self-Joins sowie Verbesserungen bei Vacuum/autovacuum. Teil 2 wird Änderungen bei Sicherheit, Monitoring, Entwicklung und logischer Replikation behandeln. Das ist ein großes Themenspektrum, aber Skip Scan ist das Feature, das das Schema-Design neu gestaltet.

Hier ist, was sich im Kern verändert hat. In PostgreSQL 17 und früher war ein mehrspaltige Index auf (a, b) nur nutzbar, wenn die WHERE-Klausel auf a oder auf a und b gemeinsam verwies. Filtert man nur nach b, hatte der Planer zwei Optionen: Sequential Scan oder einen zweiten Index ausschließlich für b anlegen. Teams bauten den zweiten Index. Dann den dritten. Dann kam die Rechnung für Write-Amplification.

Skip Scan erlaubt dem Planer, die verschiedenen Werte der führenden Spalte zu durchlaufen und den Index für jeden einzelnen zu sondieren. Die PostgreSQL-Dokumentation beschreibt die B-Tree-Zugriffsmethode so gut, dass der Mechanismus intuitiv wird, sobald man ihn sieht: Statt „ab dem führenden Schlüssel scannen" macht der Planer „für jeden unterschiedlichen führenden Schlüssel scannen". Die elf Index-Suchen im AWS-Benchmark entsprechen genau dem: 5 verschiedene Status-Werte plus die Grenzproben, die der Executor benötigt.

Der erweiterte EXPLAIN-Output ist leise der zweitwichtigste Change. Der Version-18-Plan zeigt Index Searches: 11 als erstklassigen Eintrag. Das ist genau das Signal, das man braucht, um Skip-Scan-Missbrauch im Code Review oder im Slow-Query-Log zu erkennen. Ohne diese Sichtbarkeit müsste man die Strategie aus den Buffer-Counts rekonstruieren.

Optimizer-Statistiken, die Major-Version-Upgrades überleben, sind der operativer Geheimtipp. Wer schon einmal ein Postgres-Major-Upgrade durchgeführt hat, kennt das Ritual: Umschalten, Dashboards beobachten, warten bis die Pläne regressieren, weil pg_statistic gelöscht wurde, dann um 2 Uhr nachts ANALYZE ausführen und hoffen, dass autovacuum nicht stampediert. Das Beibehalten der Statistiken über das Upgrade hinweg beseitigt eine gesamte Kategorie von Post-Cutover-Vorfällen.

Das automatische Entfernen von Self-Joins ist ein netter Gewinn auf Compiler-Ebene für ORM-generierten SQL. Vacuum-Verbesserungen sind wichtig für alle, die Tabellen mit hohem Datendurchsatz betreiben. Keines davon ist so schlagzeilenträchtig wie Skip Scan.

Was Engineering-Teams einkalkulieren sollten

Die meisten erfahrenen Postgres-Teams hatten bereits erwartet, dass PG18 Skip Scan mitbringt. Es wird seit Jahren auf der -hackers-Liste diskutiert, und Oracle sowie SQL Server haben seit einem Jahrzehnt ähnliche Funktionen. Was eingepreist ist: Das Feature existiert, es funktioniert bei führenden Spalten mit niedriger Kardinalität, und bei hoher Kardinalität hilft es nicht. Niemand mit Verstand reißt seine btree_gin-Indexes aufgrund eines Blogbeitrags heraus.

Was nicht eingepreist ist – zumindest basierend auf den Gesprächen, die ich mit Plattform-Leads geführt habe: das schiere Ausmaß der Index-Bereinigungsmöglichkeit. Viele Produktions-Schemas tragen zwei, drei, vier „Just-in-case"-Single-Column-Indexes, die gezielt hinzugefügt wurden, weil ein zusammengesetzter Index ein Abfragemuster nicht abdecken konnte. Jeder dieser Indexes kostet Write-Throughput und WAL-Volumen bei jedem INSERT und UPDATE. Skip Scan erlaubt es, einige davon zu löschen.

Die unbequeme Wahrheit: Die meisten Teams werden diese Bereinigung nicht durchführen. Sie werden PG18 einsetzen, alle bestehenden Indexes behalten und den Skip-Scan-Gewinn einfach als Bonus-Performance bei Abfragen verbuchen, die ohnehin schon gut liefen. Die Teams, die ihre Index-Liste prüfen und Redundanzen entfernen, werden die Write-Side-Gewinne sehen – und diese Gewinne tendieren dazu, über ein Quartal größer zu sein als die schlagzeilenträchtige Read-Side-Zahl.

Erwähnenswert: Aurora und RDS sind hier zeitlich aufeinander abgestimmt, was nicht immer der Fall ist. Beide Dienste haben PG18 jetzt verfügbar. Teams auf RDS müssen bei diesem Release nicht einen Zyklus hinter Aurora warten.

Gegenmeinung

Skip Scan ist in falschen Händen ein Risiko. Der AWS-Benchmark verwendete 5 verschiedene Status-Werte – das ist nahe am Idealfall. Wendet man dieselbe Optimierung auf eine führende Spalte mit einer Million verschiedener Werte an, wird der Planer CPU verbrennen, indem er Index-Proben durchführt, während ein Sequential Scan schneller fertig wäre. Der Planer soll sich durch Kostenmodellierung aus dieser Situation herausmanövrieren, aber Planer-Kostenmodelle sind bekanntermaßen optimistisch bei synthetischen Daten und pessimistisch bei echten Daten.

Der zweite Gegenpunkt: Der erweiterte EXPLAIN-Output wird eine Welle von „Warum ist meine Abfrage jetzt langsam"-Tickets erzeugen. Teams, die bisher Index Searches nicht in ihren Plänen sahen, werden hohe Zahlen sehen und in Panik geraten. Erwartet einen Anstieg von Stack-Overflow-Fragen und viel voreiligem Index-Tuning.

Drittens: Das Feature „Statistiken überleben das Major-Version-Upgrade" wird einige Teams dazu verleiten, das Post-Upgrade-Validierungsfenster zu überspringen. Dieses Fenster existiert aus Gründen, die über pg_statistic hinausgehen. Kürzt euren Canary-Zeitraum nicht, nur weil eine Klasse von Regressionen einfacher geworden ist.

Die wichtigsten Erkenntnisse

• PostgreSQL 18 Skip Scan verwandelte einen 73,2-ms-Parallel-Sequential-Scan in einen 3,4-ms-Bitmap-Index-Scan im AWS-Benchmark – eine 21-fache Beschleunigung auf einer db.r6g.large mit einer Million Zeilen.
• Der Gewinn ist am größten, wenn die führende Spalte des zusammengesetzten Indexes eine niedrige Kardinalität hat. Fünf verschiedene Werte ergaben 11 Index-Suchen. Bei führenden Spalten mit hoher Kardinalität ist dasselbe Ergebnis nicht zu erwarten.
• Prüft eure Index-Liste nach dem Upgrade. Die eigentliche Auszahlung liegt im Löschen redundanter Single-Column-Indexes, die nur hinzugefügt wurden, um die alte Planer-Einschränkung zu umgehen – das reduziert Write-Amplification und WAL-Volumen.
• Optimizer-Statistiken, die Major-Version-Upgrades überleben, beseitigen eine häufige Ursache für Plan-Regressionen nach dem Cutover – nutzt das aber nicht als Ausrede, euer Canary-Fenster zu verkürzen.
• Der erweiterte EXPLAIN-Output zeigt Index Searches jetzt als erstklassige Metrik. Fügt sie euren Slow-Query-Dashboards hinzu, bevor ihr sie braucht.