Hoewel vectordatabases nog steeds veel geldige gebruiksscenario’s hebben, vertrouwen organisaties, waaronder OpenAI, op PostgreSQL om dingen voor elkaar te krijgen.
In een blogpost op donderdagheeft OpenAI onthuld hoe het de open-source PostgreSQL-database gebruikt.
OpenAI draait ChatGPT en zijn API-platform voor 800 miljoen gebruikers op één primaire PostgreSQL-instantie – geen gedistribueerde database, geen sharded cluster. Eén Azure PostgreSQL flexibele server verwerkt alle schrijfbewerkingen. Bijna 50 leesreplica’s, verspreid over meerdere regio’s, verwerken leesbewerkingen. Het systeem verwerkt miljoenen zoekopdrachten per seconde met behoud van een lage p99-latentie van dubbele cijfers in milliseconden en een beschikbaarheid van vijf negens.
De opzet daagt de conventionele schaalwijsheid uit en biedt ondernemingsarchitecten inzicht in wat daadwerkelijk op grote schaal werkt.
TDe les hier is niet om de stapel van OpenAI te kopiëren. Het gaat erom dat architecturale beslissingen moeten worden gestuurd door werklastpatronen en operationele beperkingen, en niet door schaalpaniek of modieuze infrastructuurkeuzes. De PostgreSQL-opstelling van OpenAI laat zien hoe ver beproefde systemen zich kunnen uitstrekken wanneer teams doelbewust optimaliseren in plaats van voortijdig opnieuw te ontwerpen.
“PostgreSQL is al jaren een van de meest kritische, verborgen datasystemen die kernproducten als ChatGPT en OpenAI’s API aandrijven”, schreef OpenAI-ingenieur Bohan Zhang in een technische openbaarmaking. “Het afgelopen jaar is onze PostgreSQL-belasting ruim tien keer zo groot geworden, en deze blijft snel stijgen.”
Het bedrijf heeft deze schaalgrootte bereikt door middel van gerichte optimalisaties, waaronder het poolen van verbindingen die de verbindingstijd terugbrengen van 50 milliseconden naar 5 milliseconden en cache-locking om ‘donderende kudde’-problemen te voorkomen waarbij cachefouten de database overbelasten.
Waarom PostgreSQL belangrijk is voor ondernemingen
PostgreSQL verwerkt operationele gegevens voor ChatGPT en het API-platform van OpenAI. De werklast is sterk op lezen gericht, waardoor PostgreSQL goed past. De multiversion concurrency control (MVCC) van PostgreSQL zorgt echter voor uitdagingen bij zware schrijfbelastingen.
Bij het bijwerken van gegevens kopieert PostgreSQL hele rijen om nieuwe versies te maken, wat schrijfversterking veroorzaakt en query’s dwingt om door meerdere versies te scannen om actuele gegevens te vinden.
In plaats van deze beperking te bestrijden, heeft OpenAI zijn strategie eromheen gebouwd. Op de schaal van OpenAI zijn deze afwegingen niet theoretisch; ze bepalen welke workloads op PostgreSQL blijven en welke ergens anders heen moeten.
Hoe OpenAI PostgreSQL optimaliseert
Op grote schaal wijst de conventionele kennis van databases op een van de volgende twee manieren: verdeel PostgreSQL over meerdere primaire instanties, zodat schrijfbewerkingen kunnen worden gedistribueerd, of migreer naar een gedistribueerde SQL-database zoals KakkerlakDB of YugabyteDB ontworpen om vanaf het begin enorme schaal aan te kunnen. De meeste organisaties zouden jaren geleden een van deze paden hebben bewandeld, lang voordat ze 800 miljoen gebruikers hadden bereikt.
Door het delen of verplaatsen naar een gedistribueerde SQL-database wordt het knelpunt voor één schrijver geëlimineerd. Een gedistribueerde SQL-database handelt deze coördinatie automatisch af, maar beide benaderingen brengen aanzienlijke complexiteit met zich mee: applicatiecode moet queries naar de juiste shard routeren, gedistribueerde transacties worden moeilijker te beheren en de operationele overhead neemt aanzienlijk toe.
In plaats van PostgreSQL te sharden, heeft OpenAI een hybride strategie ontwikkeld: geen nieuwe tabellen in PostgreSQL. Nieuwe workloads zijn standaard ingesteld op sharded-systemen zoals Azure Cosmos DB. Bestaande werkbelastingen die veel schrijven vereisen en die horizontaal kunnen worden gepartitioneerd, worden gemigreerd. Al het andere blijft in PostgreSQL met agressieve optimalisatie.
Deze aanpak biedt ondernemingen een praktisch alternatief voor grootschalige herarchitectuur. In plaats van jarenlang honderden eindpunten te moeten herschrijven, kunnen teams specifieke knelpunten identificeren en alleen die werklasten naar speciaal gebouwde systemen verplaatsen.
Waarom dit ertoe doet
OpenAI’s ervaring met schaalvergroting PostgreSQL onthult verschillende praktijken die bedrijven kunnen toepassen, ongeacht hun schaalgrootte.
Bouw operationele verdedigingswerken op meerdere lagen. De aanpak van OpenAI combineert cachevergrendeling om ‘donderende kudde’-problemen te voorkomen, verbindingspooling (waardoor de verbindingstijd van 50 ms naar 5 ms daalde) en snelheidsbeperking op applicatie-, proxy- en queryniveau. Isolatie van de werkbelasting leidt verkeer met lage en hoge prioriteit naar afzonderlijke instanties, zodat een slecht geoptimaliseerde nieuwe functie de kernservices niet kan aantasten.
Beoordeel en bewaak door ORM gegenereerde SQL in productie. Object-Relational Mapping (ORM)-frameworks zoals Django, SQLAlchemy en Hibernate genereren automatisch databasequery’s op basis van applicatiecode, wat handig is voor ontwikkelaars. OpenAI ontdekte echter één door ORM gegenereerde query die twaalf tabellen samenvoegde en die meerdere zeer ernstige incidenten veroorzaakte toen het verkeer piekte. Het gemak van het laten genereren van SQL door frameworks creëert verborgen schaalrisico’s die alleen onder productiebelasting aan de oppervlakte komen. Maak van het beoordelen van deze vragen een standaardpraktijk.
Dwing strikte operationele discipline af. OpenAI staat alleen lichte schemawijzigingen toe; alles wat een volledige herschrijving van de tabel teweegbrengt, is verboden. Schemawijzigingen hebben een time-out van 5 seconden. Langdurige query’s worden automatisch beëindigd om te voorkomen dat databaseonderhoudsbewerkingen worden geblokkeerd. Bij het aanvullen van gegevens hanteren ze tarieflimieten die zo agressief zijn dat de bewerkingen meer dan een week kunnen duren.
Leeslasten met burst-schrijfbewerkingen kunnen langer op single-primary PostgreSQL draaien dan algemeen wordt aangenomen. De beslissing om te sharden moet afhangen van werklastpatronen en niet van het aantal gebruikers.
Deze aanpak is met name relevant voor AI-toepassingen, die vaak een zwaar leesgerichte werkbelasting hebben met onvoorspelbare verkeerspieken. Deze kenmerken komen overeen met het patroon waarbij single-primary PostgreSQL effectief schaalt.
De les is duidelijk: identificeer daadwerkelijke knelpunten, optimaliseer de bewezen infrastructuur waar mogelijk en migreer selectief wanneer dat nodig is. Een grootschalige herarchitectuur is niet altijd het antwoord op de schaaluitdagingen.
