Postgres 16 gegen 17 gegen 18: Gewinne, die zählen

Die drei Versionen unterscheiden sich nicht durch einen einzigen Gesamtleistungswert. Jedes korrigiert einen bestimmten Punkt der Architektur, jedes Mal mit einer anderen Zielgruppe: große Tabellen für Postgres 17, Speicher mit hoher Latenz für Postgres 18. Die folgende Tabelle fasst die überprüfbaren Fakten zusammen, alle datiert, bevor auf die Details jedes Projekts eingegangen wird.

Quellen: offizielle Versionshinweise des PostgreSQL-Projekts (postgresql.org), abgeglichen mit Analysen, die von der Microsoft Tech Community und Crunchy Data nach jeder Hauptversion veröffentlicht wurden. Zugriff am 24. August 2026.

Vor Postgres 17 speicherte VACUUM die Liste der zu bereinigenden toten Tupel in einem einfachen Array mit der Größe maintenance_work_mem. Das Problem war nicht die Geschwindigkeit der Berechnung, sondern die Struktur selbst: Diese Tabelle stagnierte bei etwa 1 GB, egal wie viel darüber hinaus konfiguriert wurde. Bei einer Tabelle mit mehr als etwa 178 Millionen toten Zeilen musste VACUUM mehrere Durchgänge durchlaufen, wobei jeder die gesamten Indizes neu las.

Postgres 17 ersetzt dieses Array durch eine Struktur namens TidStore, einen adaptiven Basisbaum, der den zum Speichern von Tupel-IDs benötigten Platz stark komprimiert. Die offiziellen Versionshinweise des Projekts weisen auf eine Reduzierung des von VACUUM genutzten Speichers um das bis zu 20-fache in einigen Fällen hin, ohne die künstliche Decke, die mit der alten Struktur verbunden war. Quelle: Offizielle Versionshinweise zu PostgreSQL 17, postgresql.org, 26. September 2024. Microsoft Tech Community und Crunchy Data veröffentlichten jeweils kurz nach der Veröffentlichung eine technische Analyse dieser Änderung. Beide bestätigen das konkrete Interesse an Tabellen mit mehreren hundert Millionen Zeilen und einer hohen Lösch- bzw. Aktualisierungsrate.

Dieses Projekt kommt hauptsächlich einem bestimmten Szenario zugute: einer großen Tabelle mit einer hohen Lösch- oder Aktualisierungsrate. VACUUM lief bisher aufgrund von Speichermangel in mehreren Durchläufen. Auf einem kleinen Tisch oder bei überwiegender Lesebelastung bleibt der Gewinn marginal oder sogar unsichtbar.

Das zweite Postgres 17-Projekt berührt einen diskreteren Punkt: die Berechnung von Transaktions-Snapshots. Jede Abfrage muss wissen, welche anderen Transaktionen gerade ausgeführt werden, um die MVCC-Sichtbarkeitsregeln von Postgres durchzusetzen. Auf einer Maschine mit einer hohen Anzahl an Kernen und aktiven Verbindungen führte diese Berechnung zu Konflikten in einer gemeinsam genutzten internen Struktur. Dies ist ein Engpass, der von Projektmitarbeitern seit langem dokumentiert wurde.

Postgres 17 reduziert diese Behauptung. Der Effekt wird hauptsächlich bei Instanzen mit hoher Parallelität gemessen, mit vielen gleichzeitig aktiven Verbindungen auf Multi-Core-Hardware. Bei einer geringen Parallelitätslast bleibt der Unterschied zu Postgres 16 marginal: Es handelt sich um ein Skalierbarkeitsprojekt und nicht um eine Reduzierung der Latenz pro isolierter Anfrage.

Dieser Gewinn ersetzt keinen Verbindungspooler, sondern reduziert lediglich dessen interne Kosten. Wenn die Anzahl der aktiven Verbindungen bereits Ihr Engpass darstellt, tritt die Hauptversion in den Hintergrund. Unser max_connections Tuning-Guide und unser PgBouncer-Transaktionsmodus-Vergleich befassen sich ausführlicher mit diesem Thema.

Postgres 18, das Ende September 2025 veröffentlicht wurde, befasst sich mit einem eher strukturellen Problem. Bis dahin blockierte jeder Lesevorgang auf der Postgres-Festplatte den Prozess, der ihn angefordert hatte. Das neue AIO-Subsystem (Asynchronous Input-Output) ermöglicht es einem Prozess, mehrere Lesevorgänge parallel zu initiieren und während des Abschlusses weiterzuarbeiten, anstatt nacheinander auf jeden einzelnen Lesevorgang zu warten.

Der Parameter io_method steuert dieses Verhalten: worker (Prozesse für E/A, Standard) oder io_uring unter Linux, wenn Postgres mit dieser Unterstützung kompiliert wurde. Sequentielle Scans, Bitmap-Heap-Scans und VACUUM sind die ersten Nutznießer, insbesondere bei Speicher mit hoher Latenz: Netzwerkfestplatten, Cloud-Volumes statt lokaler NVMe.

PlanetScale, das ein verwaltetes Postgres-Angebot anbietet, hat eigene Vergleiche zwischen Postgres 17 und 18 veröffentlicht, die sich auf diese I/O-Änderung konzentrieren. Dabei handelt es sich um ihre Messungen an der eigenen Infrastruktur, nicht um Zahlen, die wir hier unabhängig reproduziert haben. Betrachten Sie es als Signal dafür, dass es sich lohnt, das Thema unter Ihrer tatsächlichen Belastung zu testen, und nicht als universellen Prozentsatz.

Das generalisierte AIO von Postgres 18 führt ein in Postgres 17 begonnenes Projekt fort und ist keine isolierte Änderung. Version 17 hatte bereits die Streaming-I/O-Schnittstelle eingeführt, jedoch beschränkt auf ANALYZE und sequentielle Scans. Postgres 18 erweitert dieselbe Logik auf einen breiteren Bereich von Vorgängen, einschließlich VACUUM- und Bitmap-Heap-Scans. Die beiden Versionen lesen sich daher als Fortschritt und nicht als zwei separate Wetten auf I/O.

Drei weitere Postgres 18-Änderungen sind es wert, im Auge behalten zu werden, auch wenn sie sich nicht direkt auf die reine Leistung beziehen.

Der -Skip-Scan für einen mehrspaltigen B-Tree-Index ermöglicht es Postgres, einen zusammengesetzten Index zu verwenden, selbst wenn die Abfrage nicht nach seiner Kopfspalte filtert. Vor Postgres 18 erforderte dieses Szenario häufig einen vollständigen Scan der Tabelle oder die Erstellung eines zusätzlichen dedizierten Index.

Die von generierten virtuellen Spalten (GENERATED ALWAYS AS (...) VIRTUAL) werden zum Standardverhalten, wenn STORED nicht angegeben ist. Eine virtuelle Spalte wird beim Lesen berechnet und nicht auf die Festplatte geschrieben, wodurch sich die geschriebene Menge jedes Mal verringert, wenn die Quellzeile eingefügt oder aktualisiert wird.

Postgres 18 fügt neben bestehenden Mechanismen wie SCRAM, Zertifikaten oder LDAP endlich auch Unterstützung für OAuth 2.0 auf der Authentifizierungsseite (RFC 8628, Device Flow) hinzu. Ein relevanter Punkt für jede Organisation, die ihre Identitäten bereits über einen externen OAuth/OIDC-Anbieter zentralisiert.

Bei Aurabase läuft die Mandantendatenbank derzeit in Postgres 16.15 und nicht in 17. Dies kann direkt im Repository überprüft werden: Das Referenz-CNPG-Image (docker/Postgres.CNPG.Dockerfile) beginnt bei ghcr.io/cloudnative-pg/postgresql:16-standard-bookworm, gepinnt durch Digest, der gleichen Hauptversion wie die gemeinsame Ebene (docker/Postgres.Dockerfile). Verifiziert am 24. August 2026.

Der Code dokumentiert auch, warum. Ein Korrekturkommentar in k8s_tenant.rs erklärt, dass ein früherer Fallback fälschlicherweise auf postgresql:17.2verwies. Die damals angegebene Begründung, das Standardbild würde pgvector nicht enthalten, erwies sich bei der Überprüfung als falsch. Beide Bilder haben pgvector: 0,8,0 auf 17,2, 0,8,5 auf 16-Standard-Bookworm, gemessen am Flottencluster.

Das eigentliche Risiko, das im Kommentar selbst dokumentiert ist, liegt woanders: CloudNativePG verbietet jegliches Downgrade einer größeren Version, sobald ein Cluster erstellt wurde. Eine versehentlich in Postgres 17 bereitgestellte Flotte wäre irreversibel, wohingegen alles, was bei Aurabase durchgängig validiert wurde, in Postgres 16 enthalten war.

// Hauptversion bleibt erhalten, wenn TENANT_POSTGRES_IMAGE nicht definiert ist
let repli = "ghcr.io/cloudnative-pg/postgresql:16-standard-bookworm";

tracing::warn!(
    image = repli,
    "TENANT_POSTGRES_IMAGE non défini : repli sur la version validée."
);

Dies ist kein Urteil über Postgres 17 als solches. Es handelt sich um eine Richtlinie betrieblicher Vorsicht: Stellen Sie eine Produktionsflotte erst dann auf eine Hauptversion um, wenn eine End-to-End-Validierung erfolgt ist. Die gleiche Argumentation gilt für jedes Team, das Postgres über CloudNativePG oder einen gleichwertigen Kubernetes-Betreiber verwaltet. Die Frage ist nicht nur der erwartete Leistungsgewinn, sondern auch der Weg zurück, falls etwas schief geht.

Sollten Sie jetzt auf Postgres 17 oder 18 migrieren?

Drei Kriterien ermöglichen eine Entscheidung, ohne auf eine allgemeingültige Zahl warten zu müssen. Erstens die Größe und Mutationsrate Ihrer größten Tabellen: Wenn VACUUM bereits in mehreren Durchgängen ausgeführt wird, gilt die Speicher-Worksite von Postgres 17 direkt für Ihren Fall. Dann Ihr Speicher: Auf einer lokalen SSD mit geringer Latenz bietet die asynchrone E/A von Postgres 18 weniger als auf einem Netzwerkvolume. Zum Schluss noch einmal zurück: Bei einem Betreiber, der größere Downgrades verbietet, ist das erste Testen in einer Einwegumgebung keine optionale Vorsichtsmaßnahme.

Konkret gilt die gleiche Regel für jede Flotte, die von einem Kubernetes-Betreiber verwaltet wird. Stellen Sie zunächst einen Testcluster in der Zielversion bereit und spielen Sie dann darauf eine für Ihre Produktion repräsentative Auslastung ab. Fassen Sie den eigentlichen Cluster erst dann an, wenn dieser Test vollständig validiert wurde, und lesen Sie nicht nur die Versionshinweise. Wenn Ihre Entscheidung auch die Wahl zwischen einer dedizierten Basis und einer gemeinsam genutzten Basis betrifft, um diese Art von Änderung zu absorbieren, untersucht unser Artikel dedizierte vs. gemeinsam genutzte Basis diesen Aspekt.

Bei der Wahl zwischen Postgres 16, 17 und 18 kommt es nicht nur darauf an, welche Version „am schnellsten“ ist. Postgres 17 behebt ein echtes strukturelles VACUUM-Problem bei großen Tabellen und reduziert Konflikte bei hoher Parallelität. Postgres 18 geht mit asynchronem I/O noch einen Schritt weiter, einer Architekturänderung, die Tests an Ihrer tatsächlichen Last und Ihrem Speicher erfordert, bevor sie verallgemeinert wird.

Das am häufigsten vergessene Kriterium ist nicht die Leistung, sondern die Reversibilität. Bei einem Betreiber wie CloudNativePG wird ein größeres Versions-Upgrade nicht nachträglich rückgängig gemacht. Vor der Umstellung einer Produktionsflotte stellt sich nicht nur die Frage nach dem erwarteten Gewinn, sondern auch nach dem Rückweg, falls der Test fehlschlägt. Wenn Sie sich auf dieses Versions-Upgrade vorbereiten, finden Sie in unserer Postgres-Tuning-Checkliste in der Produktion Einzelheiten zu den Einstellungen, die nach einer größeren Versionsänderung erneut validiert werden müssen.