Hoewel vectordatabases nog steeds veel geldige gebruiksscenario’s hebben, vertrouwen organisaties, waaronder OpenAI, op PostgreSQL om dingen voor elkaar te krijgen.
In de blogpost donderdagOpenAI heeft onthuld hoe het de open source PostgreSQL-database gebruikt.
OpenAI draait ChatGPT en zijn API-platform voor 800 miljoen gebruikers op een enkele primaire PostgreSQL-instantie, niet op een gedistribueerde database, noch op een shardd cluster. Een flexibele Azure PostgreSQL-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 enkele dubbelcijferige milliseconden en een beschikbaarheid van vijf negens.
De opzet daagt de conventionele wijsheid van schaalbaarheid uit en geeft ondernemingsarchitecten inzicht in wat daadwerkelijk op schaal werkt.
TDe les hier is om de stapel van OpenAI niet te kopiëren. Het punt is dat architecturale beslissingen moeten worden gestuurd door werklastpatronen en operationele beperkingen, en niet door schaalpaniek of trendy infrastructuurkeuzes. De PostgreSQL-opstelling van OpenAI laat zien hoe ver beproefde systemen zichzelf kunnen pushen wanneer teams opzettelijk optimaliseren in plaats van voortijdig opnieuw te ontwerpen.
“PostgreSQL is jarenlang een van de meest kritische en verborgen datasystemen geweest die kernproducten als ChatGPT en de OpenAI API aandrijven”, schreef OpenAI-ingenieur Bohan Zhang in een technische openbaarmaking. “Het afgelopen jaar is onze PostgreSQL-belasting meer dan tien keer zo groot geworden en blijft snel groeien.”
Het bedrijf heeft dit bereikt door middel van gerichte optimalisaties, waaronder het poolen van verbindingen die de verbindingstijden terugbrachten van 50 milliseconden naar 5 milliseconden, en cache-pinning om ‘donderende kudde’-problemen te voorkomen waarbij cache-missers overbelasting van de database veroorzaken.
Waarom PostgreSQL belangrijk is voor bedrijven
PostgreSQL beheert operationele gegevens voor ChatGPT en het API-platform van OpenAI. De werklast is sterk leesgericht, wat PostgreSQL een goede oplossing maakt. De multi-version 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, waardoor schrijfversterking ontstaat en query’s worden gedwongen meerdere versies te scannen om de huidige gegevens te vinden.
In plaats van deze beperking te bestrijden, heeft OpenAI zijn strategie eromheen gebouwd. Op OpenAI-schaal 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: splits PostgreSQL over meerdere primaire instanties zodat schrijfbewerkingen kunnen worden gedistribueerd, of migreer naar een gedistribueerde SQL-database als DB-kakkerlak o YugabyteDB is vanaf het begin ontworpen om grote formaten te verwerken. De meeste organisaties zouden jaren geleden een van deze paden hebben bewandeld, lang voordat ze de 800 miljoen gebruikers bereikten.
Door het partitioneren of verplaatsen naar een gedistribueerde SQL-database wordt het knelpunt voor één enkele schrijver geëlimineerd. Een gedistribueerde SQL-database verwerkt deze coördinatie automatisch, 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 partitioneren, heeft OpenAI een hybride strategie ontwikkeld: geen nieuwe tabellen in PostgreSQL. De nieuwe workloads worden standaard gebruikt op gepartitioneerde systemen zoals Azure Cosmos DB. Bestaande schrijfintensieve werkbelastingen die horizontaal kunnen worden gepartitioneerd, worden gemigreerd. Al het andere blijft in PostgreSQL met agressieve optimalisatie.
Deze aanpak biedt bedrijven een praktisch alternatief voor grootschalige herinrichting. 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 belangrijk is
OpenAI’s ervaring met het opschalen PostgreSQL onthult verschillende praktijken die bedrijven kunnen toepassen, ongeacht hun omvang.
Bouw meerlaagse operationele verdedigingswerken. De aanpak van OpenAI combineert cache-pinning om “donderende kudde” -problemen te voorkomen, pooling van verbindingen (waardoor de verbindingstijd werd teruggebracht 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 bewaak SQL gegenereerd door ORM 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 een door ORM gegenereerde query die twaalf tabellen samenvoegde en die meerdere zeer ernstige incidenten 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.
Pas een strikte operationele discipline toe. 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. Wanneer ze de gegevens invullen, passen ze tarieflimieten toe die zo agressief zijn dat operaties meer dan een week kunnen duren.
Leeslasten met burst-schrijfbewerkingen kunnen langer op single-primary PostgreSQL draaien dan vaak 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 zware leesbelasting hebben met onvoorspelbare verkeerspieken. Deze kenmerken komen overeen met het model waarin PostgreSQL single-primary effectief schaalt.
De les is simpel: identificeer daadwerkelijke knelpunten, optimaliseer de bewezen infrastructuur waar mogelijk en migreer selectief wanneer dat nodig is. Een totale herarchitectuur is niet altijd het antwoord op schaalbaarheidsproblemen.
