- OpenAI teilte auf der PGConf.dev 2025 mit, wie das Unternehmen PostgreSQL ohne Sharding einsetzt und dabei den Traffic von Hunderten Millionen Nutzern effektiv verarbeitet
- Um das Problem des Schreib-Bottlenecks zu lösen, wurden verschiedene Ansätze eingeführt, darunter Verteilung von Schreiblast, Query-Optimierung und Schema-Management
- Als zentrale Themen wurden strukturelle Grenzen und operative Schwierigkeiten von PostgreSQL genannt, etwa Tabellen-/Index-Aufblähung durch das MVCC-Design und Replikationsverzögerungen durch WAL
- Zentral sind Strategien zur Verteilung der Leselast, Begrenzung langer Transaktionen und Minimierung des ORM-Einsatzes
- OpenAI erreicht 1 Million QPS mit mehr als 40 geografisch verteilten Replikaten und gewährleistet auch bei Ausfällen eine hohe Verfügbarkeit
OpenAIs Fallstudie zur großskaligen PostgreSQL-Skalierung
Hintergrund
- Viele Kerndienste von OpenAI hängen von PostgreSQL ab
- Ein Datenbankausfall wirkt sich direkt auf das gesamte Serviceangebot aus
- In der Vergangenheit kam es bei wichtigen Diensten, darunter ChatGPT, bereits zu Ausfällen aufgrund von PostgreSQL-Problemen
- OpenAI betreibt auf einer verwalteten Azure-Datenbank eine Primary-Replica-Architektur (eine einzelne Primary + mehr als 40 Replicas)
- In einer Umgebung mit 500 Millionen monatlich aktiven Nutzern ist Skalierbarkeit ein Schlüsselfaktor für den geschäftlichen Erfolg
Zentrale Herausforderungen
- Lese-Traffic kann auf viele Replicas verteilt werden, doch Schreibanfragen konzentrieren sich auf eine einzelne Primary und verursachen dadurch einen Bottleneck
- Wichtige Verbesserungsansätze
- Alle möglichen Schreibanfragen auslagern und verteilen
- Zusätzliche direkte Zugriffe neuer Services auf die Primary-DB minimieren
- Aufgrund der Struktur von MVCC (Multiversion Concurrency Control) gibt es Nachteile wie Tabellen-/Index-Aufblähung, komplexes Tuning der Garbage Collection und Sichtbarkeitsprüfungen von Indizes
- Mit steigender Zahl an Replicas nimmt auch der WAL (Write-Ahead Logging)-Traffic stark zu, wodurch die Netzwerkbandbreite zu einem weiteren Bottleneck wird
Gegenmaßnahmen
Lastverteilung auf der Primary-Datenbank
- Prognose und Entschärfung der Schreiblast:
- Alle möglichen Schreibvorgänge auslagern
- Unnötige Schreibvorgänge auf Anwendungsebene verhindern
- Lazy Write anwenden und den Zyklus von Daten-Backfills anpassen
- Leselast wird so weit wie möglich auf Replicas verteilt; wenn Verarbeitung auf der Primary unvermeidbar ist, muss sie hoch effizient erfolgen
Query-Optimierung
- Lang laufende Transaktionen belegen Systemressourcen über lange Zeit und verzögern die Garbage Collection
- Timeouts pro Sitzung, Query und Client anwenden sowie Sessions im Zustand Idle in transaction begrenzen
- Es wird ausdrücklich darauf hingewiesen, dass der Einsatz von ORM die Ineffizienz erhöhen kann; empfohlen wird ein vorsichtiger Umgang
- Optimierung komplexer Multi-Join-Queries (z. B. Join über 12 Tabellen)
Umgang mit Single Point of Failure (SPOF)
- Fällt die Primary aus, sind keine Schreibvorgänge möglich; bei teilweisen Ausfällen von Replicas bleibt die Lesekontinuität erhalten
- Wichtige Anfragen (hohe Priorität) werden über dedizierte Replicas verarbeitet, um Interferenzen durch Anfragen mit niedriger Priorität zu minimieren
Schema-Management
- Das Erstellen neuer Tabellen und die Einführung neuer Workloads sind im Cluster eingeschränkt
- Das Hinzufügen/Entfernen von Spalten ist nur für leichte Operationen innerhalb eines Limits von 5 Sekunden erlaubt; Operationen, die ein vollständiges Rewrite der Tabelle erfordern, sind nicht zulässig
- Das Erstellen/Entfernen von Indizes ist nur mit der Option
CONCURRENTLY erlaubt
- Ein Problem besteht darin, dass lang laufende Queries von mehr als 1 Sekunde Schemaänderungen fortlaufend blockieren; solche Queries müssen daher auf Anwendungsebene optimiert oder ausgelagert werden
Betriebsergebnisse
- Im gesamten Cluster werden 1 Million QPS (Lesen + Schreiben) verarbeitet und die wichtigsten OpenAI-Dienste unterstützt
- Auch nach dem Hinzufügen von rund 40 Replicas stieg die Replikationsverzögerung nicht an
- Read-only Replicas sind in verschiedenen Regionen platziert und halten die Latenz niedrig
- In den letzten 9 Monaten gab es nur einen PostgreSQL-bezogenen SEV0-Ausfall
- Ausreichende Kapazität für weiteres Wachstum wurde gesichert
Ausfallbeispiele
- Cascading Effect infolge eines Cache-Fehlers
- Ein Bug, bei dem der WALSender-Prozess bei hoher CPU-Auslastung den WAL-Versand stoppt und in einen Loop-Zustand gerät → Replikationsverzögerung
Vorgeschlagene Funktionsverbesserungen für PostgreSQL
- Index-Management: Vorschlag für eine Disable-Funktion, um unnötige Indizes sicher zu deaktivieren und so Risiken vor dem Löschen zu minimieren
- Observability: Wunsch nach latency-basierten Histogramm-/Perzentil-Metriken wie p95 und p99
- Schemaänderungsverlauf: Bedarf an einer Funktion zum Speichern von Schemaänderungen wie DDL
- Klarere Bedeutung von Monitoring-Views: Fragen zu Ursachen und Gegenmaßnahmen bei Sessions, die lange im Zustand ClientRead verbleiben
- Optimierung von Standardparametern: Die Standardwerte von PostgreSQL seien zu konservativ; gewünscht werden bessere Defaults oder Heuristiken
Kommentar von Lao Feng
- OpenAIs Skalierungsstrategie unter solch extremen Bedingungen ist für Core-PostgreSQL-Entwickler als Praxisbeispiel sehr wertvoll
- Ähnliche Erfahrungen gibt es auch bei großen Diensten wie Chinas Tantan (33 Replicas, 400.000 QPS, eingeführtes anwendungsseitiges Sharding)
- In heutigen Hochleistungs-Hardware-Umgebungen deutet dies darauf hin, dass aggressive Skalierung wie bei OpenAI auch mit einem einzelnen PostgreSQL-Cluster realistisch ist und eine verteilte DB nicht zwingend erforderlich sein muss
- OpenAI nutzt verwaltetes PostgreSQL auf Azure, mehr als 40 Replicas, Cross-Region-Deployment sowie Kubernetes + PgBouncer
- Trotz intensiver Unterstützung durch das Azure-PostgreSQL-Team bleiben operative Fähigkeiten bei Anwendung/DBA und Observability essenziell
- Erwähnt werden Monitoring über Datadog sowie die Belastung durch Performance- und Kostenaspekte
- Betriebs-Know-how, Ausfallerfahrungen und DBA-Assets sind entscheidend für die Servicequalität
Lao Feng Q&A
Funktion zum Deaktivieren von Indizes
- In PostgreSQL lässt sich ein Index intern über das Feld indisvalid deaktivieren (allerdings ist dafür superuser-Berechtigung erforderlich, in RDS-Umgebungen eingeschränkt)
- Die praktische Alternative besteht darin, die Indexnutzung per Monitoring zu prüfen und den Index anschließend sicher zu löschen
Erweiterte Observability: P95/P99-Latenz
- Die Unterstützung von Perzentil-Metriken in pg_stat_statements ist wegen des Speicher-Overheads schwierig; Ausweichmöglichkeiten sind pg_stat_monitor, eBPF oder Latenz-Monitoring auf Anwendungsebene
- In verwalteten Azure-PostgreSQL-Umgebungen werden einige Optionen (Serverzugriff, eBPF usw.) nicht unterstützt
Schemaänderungsverlauf
- Nutzbar sind Logdateien, pgaudit, CREATE EVENT TRIGGER, pg_ddl_historization usw. (allerdings ist dafür superuser-Berechtigung erforderlich, mit Einschränkungen beim Azure-RDS-Support)
- Gewünscht ist eine Form der Verlaufsspeicherung als abfragbare System-View oder Tabelle
Bedeutung von Monitoring-Views
- Die Kombination State=Active + WaitEvent=ClientRead bedeutet, dass während der Statement-Ausführung auf Eingaben des Clients gewartet wird; das muss nicht zwingend ein Bug sein und kann verschiedene Ursachen haben
- Durch Begrenzung der Verbindungsdauer (z. B. Ablauf von Verbindungen in der Netzwerkschicht via HAProxy, Lebensdauerverwaltung im clientseitigen Connection Pool) lassen sich Nebenwirkungen minimieren; ob Azure dies unterstützt, ist unklar
Standardparameter
- Die Standardwerte von PostgreSQL sind zwar zu konservativ, können aber durch service-spezifische Heuristiken oder automatisiertes Parameter-Tuning (RDS, Pigsty usw.) ergänzt werden
- Falls PostgreSQL-Tools künftig Hardware-Spezifikationen automatisch erkennen und anwenden, dürfte dies die Last im Betrieb verringern
Option Eigenbetrieb (Self-Hosting)
- Praktische Betriebsprobleme ergeben sich weniger aus PostgreSQL selbst als aus den Grenzen des verwalteten Azure-Angebots
- Beim eigenständigen Aufbau eines PostgreSQL-Clusters auf NVMe-SSDs in einer IaaS-Umgebung (z. B. mit Pigsty) steigt die funktionale und operative Flexibilität
- Mit Lösungen wie Pigsty ließen sich die meisten Anforderungen von OpenAI proaktiv erfüllen; je nach Größe und Anforderungen ist der Einsatz daher erwägenswert
2 Kommentare
Hacker-News-Kommentare
Letzte Woche war ich auf der PGConf, und es war beeindruckend, dass dieser Vortrag zu den am stärksten besuchten Sessions gehörte, besonders weil die Konferenz eher nach innen gerichtet war und die meisten Sessions sich auf die Entwicklung von Postgres selbst konzentrierten. Man sollte sich immer bewusst machen, dass viele Teams bei erfolgreichem Produktwachstum nicht wirklich tief verstehen, wie sie bestimmte Teile ihres Stacks skalieren sollen; dieser Vortrag wurde als großartige Geschichte darüber bewertet, wie ein kleines Team Probleme überwindet und dabei lernt. Statt vereinfachter Reaktionen wie „Sollte man das nicht so machen?“ habe die Session mit einer echten Nutzerstory den Wachstumsprozess und die hohe Popularität des Produkts lebendig gezeigt und damit perfekt zu einer entwicklerzentrierten Veranstaltung gepasst. Die Kernbotschaft des Vortrags sei gewesen, dass man Postgres, sofern man nicht viele Schreibvorgänge hat, allein mit Read Replicas und einer Single-Master-Architektur auf gewaltigen Read-Durchsatz skalieren kann. Genau diese Botschaft treffe auf die meisten Anwendungen zu. In der Q&A-Zeit hätten vor allem Postgres-Core-Entwickler Fragen gestellt, um den Use Case besser zu verstehen, kaum mit kritischer Absicht; insgesamt wirke die Postgres-Community wirklich freundlich und offen
Zur Botschaft „Wenn man nicht viele Schreibvorgänge hat, kann man mit Single Master und Read Replicas den Read-Durchsatz von Postgres stark skalieren“: Aus System-Design-Interviews habe ich den Eindruck gewonnen, dass viel zu viele Bewerber schon bei einfachen Systemen mit vielleicht fünf Reads pro Sekunde sofort riesige verteilte Strukturen oder letztlich inkonsistente Systeme einführen wollen. Selbst zehn Millionen Nutzer seien eigentlich keine so große Größenordnung. Während die gesamte Branche auf horizontale Skalierung fixiert sei, sollten mehr Leute wahrnehmen, dass reale Hardware schneller und größer geworden ist, als viele sich vorstellen. Man kann bei Amazon inzwischen Server mit 32 TB RAM mieten. Auch bei größerem Maßstab seien ACID-Garantien weiterhin enorm wertvoll
Danke, das war wirklich genau die Kernbotschaft, die der Vortrag vermitteln sollte (Bohan)
Frage, ob es irgendwo die Folien oder eine Aufzeichnung dieses Vortrags gibt
Eindruck, dass dieser Thread dem Team gegenüber etwas hart urteilt. Erfahrene HN-Nutzer in diesem Bereich interessieren sich laut Erklärung dafür, wie man einen Dienst im Stil von ChatGPT architektonisch skaliert und wie ein Unternehmen mit praktisch unbegrenzten Ressourcen einstellt. Dass die Botschaft des Vortrags „Mit ORMs entstehen leicht ineffiziente Queries, also Vorsicht“ lautet, sei selbst ein Hinweis darauf, dass das Team im Betrieb einer Infrastruktur dieser Größenordnung noch nicht sehr erfahren sei
Aus Flexibilitätsgründen ist Self-Hosting von Postgres attraktiv, etwa wegen Superuser-Rechten oder fortgeschrittener Features, aber es fühlt sich trotzdem nach etwas an, um das man sich ungern selbst kümmern möchte. Es wäre schön, wenn Cloud-Anbieter standardmäßig eine Funktion unterstützen würden, mit der man einen Index im Query Planner deaktivieren kann, bevor man ihn wirklich droppt. Für ein Großunternehmen erscheint Self-Hosting zur Anpassung des Stacks durchaus vernünftig
Es gibt in Postgres bereits verschiedene Möglichkeiten, einen bestimmten Index zu nutzen oder zu deaktivieren, und diese kann man auch in Cloud-Managed-Postgres-Instanzen verwenden. Zum Beispiel kann man Query-Planner-Einstellungen pro Query anpassen (etwa
enable_indexscan=off), imWHERE-Teil einfache arithmetische Operationen einfügen, damit absichtlich kein Index verwendet wird, oder die Erweiterungpg_hintplannutzen (damit kann man per Kommentar angeben, welcher Index verwendet werden soll, siehe: https://pg-hint-plan.readthedocs.io/en/latest/hint_table.html#hints-for-scan-methods)Zur Einordnung: Ich arbeite im Azure-Postgres-Team, und OpenAI nutzt kein Self-Hosting, sondern Azure Managed PostgreSQL (Flexible Server)
Der OpenAI-Sprecher (Bohan) hat selbst klargestellt, dass sie keine Self-Hosting-Umgebung betreiben, sondern Azure Database for PostgreSQL verwenden. Er entschuldigte sich dafür, dass im Vortrag zwar mehrfach „Azure Postgres“ gesagt wurde, aber nicht klar genug herausgestellt wurde, dass es sich um einen von Microsoft verwalteten Dienst handelt
Überraschend sei, dass es in Postgres nichts Vergleichbares zu dem DDL-Feature in MySQL oder MariaDB gibt, mit dem man Indizes als INVISIBLE oder IGNORED markieren kann, damit der Query Planner sie ignoriert
Zitiert nur den Originalsatz „Der Vorteil von Self-Hosting von postgres ist Flexibilität…“
Auf die Bitte nach einer Funktion, die die Historie von Schemaänderungsereignissen (Spalten hinzufügen/entfernen usw.) protokolliert, kam der Hinweis, dass sich das bereits in Echtzeit mit EVENT TRIGGER umsetzen lässt; als Beispiel wurde auf Aquameta verwiesen (https://github.com/aquametalabs/aquameta)
Wir implementieren in unserer eigenen Postgres-Umgebung ebenfalls eine Versionsverwaltung für DDL-Änderungen. Postgres selbst ist sehr leistungsfähig, sodass man das auf viele Arten umsetzen kann, aber Versionshistorie und Betriebs-Logs für große oder kritische Datenbanken seien auch sehr häufige Anforderungen. Die meisten würden erst durch schmerzhafte eigene Erfahrungen erkennen, wie wichtig das ist. Nicht nur DDL-Änderungen, sondern auch wichtige Betriebsrichtlinien, etwa Änderungen am Preismodell oder an SKU-/Preis-Anpassungen, müssten unbedingt auditierbar sein. Wenn man ein vollständig relationales Modell entwirft, stelle sich in echten Anwendungen oft heraus, dass nur ein Teil der Tabellen häufig geändert wird, während die meisten praktisch „statische“ Tabellen sind. Wenn sich solche Tabellen ändern, sollte man die Historie sorgfältig festhalten, damit sich frühere Daten besser interpretieren oder zurückrollen lassen
Wir bei Xata nutzen sowohl pgroll (https://github.com/xataio/pgroll) als auch pgstream (https://github.com/xataio/pgstream); beide verwenden EVENT TRIGGER, um DDL-Änderungen zu erkennen, Schema-Migrationshistorien zu protokollieren oder Schemaänderungsereignisse in einen Stream der logischen Replikation einzubeziehen. Allerdings beschränken die meisten Postgres-basierten DBaaS-Angebote EVENT TRIGGER teilweise wegen der nötigen Superuser-Rechte; RDS/Aurora und Xata unterstützen es, und Supabase bereitet Unterstützung ebenfalls vor
Danke, dass du dich an Aquameta erinnerst, und kleiner Teaser: Bald kommt eine tolle neue Funktion
Diese Dinge – gleichzeitige Index-Erstellung im großen Maßstab, Vermeidung von Table Rewrites, Traffic-Verteilung, Transaction Timeouts, Read Replicas – seien in Wahrheit schon bei deutlich kleineren Größenordnungen als bei OpenAI fast unverzichtbar beziehungsweise Standardwissen. Auch die an Postgres gerichteten Wünsche seien Dinge, die schon seit Langem viele fordern. Obwohl der Titel „Next Level“ lautet, sehe es in Wirklichkeit eher nach einem verzweifelten Versuch aus, Single Master um jeden Preis beizubehalten und damit unter Einschränkungen bei neuen Workloads weiter zu skalieren. Der Kernpunkt sei, hohe Read-Last ordentlich auszuhalten, und das sei im Grunde längst die Standardstrategie mit Read Replicas und horizontaler Verteilung. Auch die Methode zum Deaktivieren eines Indexes über Eingriffe in ein internes Feld (
indisvalid) sei offiziell nur ein Trick und nicht als reguläre Funktion vorgesehen; solche Anpassungen an den Systemkatalog seien riskant. Auch die Empfehlung, die Indexnutzung über Monitoring-Views zu prüfen und dann zu droppen, sei keine perfekte Lösung; um verlässlich zu beurteilen, welche Indizes nötig oder unnötig sind, müsse man zusätzlich die Query-Pläne ansehenIm Originalartikel steht, OpenAI verarbeite auf Azure eine Million Queries pro Sekunde; das sei in einer realen Cloud-Umgebung, besonders mit netzwerkbasiertem Storage, durchaus beeindruckend. Andererseits verteile sich das insgesamt auf rund 40 Read Replicas, also etwa 25.000 QPS pro einzelner Instanz, was nicht ganz so erstaunlich sei. Zur Debatte über die Indexnutzung wurde angemerkt, dass es bei aktuellen Statistiken und einem ordentlichen Verständnis der DB-Eigenschaften ausreiche zu prüfen, welcher Index geeignet ist und ob die Bedingungen/Projektionen der Query dem Left-most Prefix des Indexes gut folgen
Es wird überhaupt nicht erklärt, warum OpenAI kein Postgres-Sharding macht, was ehrlich gesagt frustrierend sei. Schon Sharding pro Nutzer würde das Problem wohl viel einfacher lösen; warum also an Single Master festhalten?
Es sah so aus, als würden sie physische Replikation verwenden; ich überlege gerade selbst, aus Kostengründen auf logische Replikation umzusteigen, vor allem um ausgehenden Traffic zwischen Regionen zu reduzieren. Seit Postgres 17 scheint sich die native logische Replikation stark verbessert zu haben; mich würde interessieren, ob das in der Praxis inzwischen gut genug ist
Um unterschiedlichste Queries zu bedienen, werden sie vermutlich auch andere Storage-Engines parallel einsetzen – Key-Value, Suche, Vektorsuche, Cache usw. –, daher wirke es seltsam, dass sich der Vortrag ausschließlich auf Postgres konzentrierte. Vermutung, dass intern in Wirklichkeit verschiedene Strategien für Traffic- und Load-Balancing eingesetzt werden
Frage, ob bessere Performance möglich wäre, wenn man nur die Write-Instanz direkt auf dedizierten Servern mit lokalen schnellen SSDs betreibt und Reads ausschließlich über einen Managed Service abwickelt
Deutliche Forderung: „Shardet die DB doch einfach.“ Schon Sharding nach Nutzer/Organisation würde die derzeitigen Hauptprobleme einfach lösen. Mehrfach komplexe Umgehungslösungen zu versuchen, wirke eher wie ein Umweg
Im Vortrag sei gerade die zentrale Botschaft gewesen, dass man auch ohne Sharding allein mit einer Single-Master-Architektur bis zu sehr hohen Durchsatzwerten skalieren kann; natürlich habe man auch Sharding geprüft, aber die Trade-offs hätten nicht gepasst, und die aktuelle Struktur lasse sich ebenfalls skalieren
Direkte Antwort des OpenAI-Sprechers (Bohan): Das Sharding der Workloads sei nicht so einfach. Workloads mit bereits hoher Schreiblast seien schon aus PostgreSQL herausgelöst und würden in Shards verarbeitet; das, was noch übrig sei, sei fast nur noch Read-only, sodass die Einführung von Sharding enorme Arbeit bedeuten würde. Aktuell sei man der Ansicht, dass Azure Database for PostgreSQL allein schon genügend Skalierbarkeit und Reserven für die Zukunft biete. Langfristig werde Sharding nicht vollständig ausgeschlossen, kurzfristig habe es aber keine Priorität
Sharding sei nicht so simpel, wie es klingt. Der Grund, eine leistungsfähige Datenbank zu verwenden, liege gerade darin, komplexe Datenanalysen und Queries ausführen zu können; wenn es nur um einfaches Speichern und Verteilen ginge, wären mehrere NFS-Mounts letztlich einfacher
Der realistische Einwand, dass man auf eine so enorme Datenbank mit einer Million Queries pro Sekunde nicht einfach „wendet doch Sharding an“ anwenden kann. Auch wenn Organisationen als Sharding-Key naheliegend wirken, sei auf dieser Größenordnung nichts mehr wirklich einfach
Deutliche Zustimmung zu diesem Argument
Zur Aussage im Vortrag, man solle ORMs vorsichtig einsetzen: Persönliche Ansicht, dass alle ORMs – besonders solche für mehrere Datenbanken – problematisch sind. Durch ORMs denke man über Datenmuster nur noch auf Ebene des Anwendungscodes nach und könne am Ende kaum noch die starken datenbankspezifischen Features nutzen. Ich selbst nutze überhaupt keine ORMs und setze aktiv auf Postgres-spezifische Queries und Funktionen; es lohne sich viel mehr, sich weniger auf Sprache oder Bequemlichkeit und stärker auf die Power der DB zu konzentrieren. Am Ende mache gut geschriebenes SQL das gesamte System glücklicher
Beim früheren Wechsel von DB2 zu psql habe ein ORM sehr geholfen, um die Downtime zu minimieren. Dank des ORMs konnte der Datenbankwechsel transparent erfolgen, man musste den Großteil der Logik kaum anfassen, und nicht alle Entwickler sind darin geübt, selbst Queries zu schreiben; wenn Queries direkt im Code verteilt sind, werde Refactoring oder das Verständnis schnell schwierig. Letztlich werde auch SQL als Bibliothek abstrahiert werden
Nach langer Nutzung des Django ORM hatte ich den Eindruck, dass es wirklich hervorragende Software ist, aber seit ich sqlc verwende, wirkt der Ansatz, Queries direkt in Go-Code zu übersetzen, eher wie der ideale Kompromiss zwischen ORM und Raw SQL
Vielleicht hast du einfach noch nie ein wirklich gutes ORM erlebt, etwa Entity Framework Core
Leichte Anmerkung, dass „Scaling PostgreSQL to the Next Level at OpenAI“ wohl der passendere eigentliche Vortragstitel wäre
Anscheinend werden kommerzielle Produkte wie Oracle RAC oder DB2 pureScale, die Multi-Write ermöglichen, wohl nicht in Betracht gezogen, oder?