Hoewel vectordatabases nog steeds veel geldige gebruiksscenario’s hebben, vertrouwen organisaties, waaronder OpenAI, op PostgreSQL om dingen voor elkaar te krijgen.
In één blogpost op donderdagOpenAI onthulde hoe het de open-source PostgreSQL-database gebruikt.
OpenAI draait ChatGPT en zijn API-platform voor 800 miljoen gebruikers op één enkele 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 tot negen.
De opzet daagt de conventionele schaalwijsheid uit en geeft ondernemingsarchitecten inzicht in wat daadwerkelijk werkt op grote schaal.
Tde les hier is om de stapel van OpenAI niet 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 datasystemen onder de motorkap die kernproducten als ChatGPT en OpenAI’s API aandrijven”, schreef OpenAI-ingenieur Bohan Zhang in een technische openbaarmaking. “Het afgelopen jaar is onze PostgreSQL-werklast ruim tien keer zo groot geworden en blijft snel groeien.”
Het bedrijf heeft deze schaalgrootte bereikt door gerichte optimalisaties, waaronder het poolen van verbindingen, waardoor de verbindingstijd werd teruggebracht van 50 milliseconden naar 5 milliseconden, en cache-locking om ‘netelige kudde’-problemen te voorkomen, waarbij cache-missers tot overbelasting van de database leiden.
Waarom PostgreSQL belangrijk is voor bedrijven
PostgreSQL verwerkt operationele gegevens voor ChatGPT en het API-platform van OpenAI. De werklast is sterk op lezers gericht, waardoor PostgreSQL goed past. De multiversion concurrency control (MVCC) van PostgreSQL zorgt echter voor uitdagingen bij zware schrijfbelastingen.
Wanneer u gegevens bijwerkt, 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 naartoe moeten worden verplaatst.
Hoe OpenAI PostgreSQL optimaliseert
Op grote schaal wijst conventionele databasewijsheid op een van de volgende twee paden: 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 bereikten.
Door het delen of verplaatsen naar een gedistribueerde SQL-database wordt het knelpunt voor één auteur 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 kosten stijgen aanzienlijk.
In plaats van PostgreSQL te doorbreken, heeft OpenAI een hybride strategie ontwikkeld: geen nieuwe tabellen in PostgreSQL. Nieuwe workloads zijn standaard sharded-systemen zoals Azure Cosmos DB. Bestaande schrijflasten die horizontaal kunnen worden gesplitst, worden gemigreerd. Al het andere blijft in PostgreSQL met agressieve optimalisatie.
Deze aanpak biedt bedrijven 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 benaderingen die bedrijven kunnen gebruiken, ongeacht hun schaalgrootte.
Bouw meerlaagse operationele verdedigingswerken. De aanpak van OpenAI combineert cachevergrendeling om ‘donder-veranderende kudde’-problemen te voorkomen, verbindingspooling (waardoor de verbindingstijd werd verlaagd van 50 ms naar 5 ms) en snelheidsbeperking op applicatie-, proxy- en queryniveau. Workload-isolatie leidt verkeer met lage en hoge prioriteit naar afzonderlijke instances, zodat een slecht geoptimaliseerde nieuwe functie de kernservices niet kan aantasten.
Beoordeel en monitor 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. Maar OpenAI ontdekte dat een door ORM gegenereerde zoekopdracht die twaalf tabellen samenvoegde, meer ernstige gebeurtenissen veroorzaakte naarmate het verkeer toenam. Het gemak van het laten genereren van SQL door frameworks creëert verborgen schaalrisico’s die alleen onder productiebelasting naar voren 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 tabelherschrijving activeert, is verboden. Schemawijzigingen hebben een time-out van 5 seconden. Langdurige query’s worden automatisch beëindigd om te voorkomen dat databaseonderhoudsbewerkingen worden geblokkeerd. Wanneer ze gegevens invullen, handhaven ze de snelheidslimieten zo agressief dat de operaties meer dan een week kunnen duren.
Leesintensieve workloads met burst-writes kunnen langer op single-primary PostgreSQL draaien dan vaak wordt gedacht. De beslissing om te bezuinigen moet afhangen van werklastpatronen en niet van gebruikersaantallen.
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 waarin single-primary PostgreSQL efficiënt 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.
