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 donderdagOpenAI onthult hoe ze de open source PostgreSQL-database gebruiken.
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 regio’s verwerken leesbewerkingen. Het systeem verwerkt miljoenen zoekopdrachten per seconde met behoud van een latentie van p99 milliseconden met dubbele cijfers en een beschikbaarheid van vijf tot negen.
Deze opzet daagt de conventionele schaalwijsheid uit en biedt ondernemingsarchitecten inzicht in wat echt op schaal werkt.
QDe les hier is om de OpenAI-stack niet te kopiëren. Architectuurbeslissingen moeten worden ingegeven door werklastpatronen en operationele beperkingen – niet door schaalpaniek of modieuze infrastructuurkeuzes. De PostgreSQL-opstelling van OpenAI laat zien hoe ver een beproefd systeem kan gaan als teams opzettelijk optimaliseren in plaats van voortijdig opnieuw te ontwerpen.
“PostgreSQL is jarenlang een van de belangrijkste en meest verborgen datasystemen geweest die kernproducten zoals ChatGPT en OpenAI API’s ondersteunen”, schreef OpenAI-ingenieur Bohan Zhang in zijn technische onthulling. “Het afgelopen jaar is onze PostgreSQL-belasting meer dan 10x toegenomen, en blijft snel toenemen.”
Het bedrijf heeft deze schaal bereikt door middel van gerichte optimalisaties, waaronder het poolen van verbindingen die de verbindingstijden terugbrengen van 50 milliseconden naar 5 milliseconden en cache-locking om ’thunder swarm’-problemen te voorkomen waarbij cache-missers database-overbelasting veroorzaken.
Waarom PostgreSQL belangrijk is voor bedrijven
PostgreSQL verwerkt operationele gegevens voor ChatGPT en het OpenAI API-platform. De werklast is zeer leesgericht, dus PostgreSQL past uitstekend. De multiversion concurrency control (MVCC) van PostgreSQL zorgt echter voor uitdagingen bij zware schrijfbelastingen.
Bij het bijwerken van gegevens kopieert PostgreSQL hele rijen om een nieuwe versie te maken, waardoor schrijfversterking ontstaat en de query wordt gedwongen meerdere versies te scannen om de huidige gegevens te vinden.
In plaats van deze beperkingen te bestrijden, bouwt OpenAI zijn strategie hieromheen. Op de schaal van OpenAI zijn deze afwegingen niet theoretisch: ze bepalen welke werklasten in PostgreSQL blijven en welke ergens anders naartoe moeten verhuizen.
Hoe OpenAI PostgreSQL optimaliseert
Op grote schaal leidt conventioneel databasebeleid tot 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 is vanaf het begin ontworpen om op grote schaal te kunnen werken. 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 de barrière voor één enkele schrijver geëlimineerd. Gedistribueerde SQL-databases voeren deze coördinatie automatisch uit, maar beide benaderingen brengen aanzienlijke complexiteit met zich mee: applicatiecode moet queries naar de juiste shards routeren, gedistribueerde transacties worden moeilijker te beheren en de operationele overhead neemt aanzienlijk toe.
In plaats van PostgreSQL te sharden, koos OpenAI voor een hybride strategie: geen nieuwe tabellen in PostgreSQL. Nieuwe werkbelastingen worden standaard toegewezen aan shardingsystemen 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 bedrijven een praktisch alternatief voor grootschalige herarchitectuur. In plaats van jarenlang honderden eindpunten te moeten herschrijven, kunnen teams specifieke knelpunten identificeren en die werklasten eenvoudigweg verplaatsen naar een op maat gemaakt systeem.
Waarom dit belangrijk is
De schaalervaring van OpenAI PostgreSQL bracht verschillende praktijken aan het licht die bedrijven ongeacht de schaal kunnen implementeren.
Bouw operationele verdedigingswerken op meerdere lagen. De aanpak van OpenAI combineert cachevergrendeling om het “schokkende zwerm”-probleem te voorkomen, pooling van verbindingen (waardoor de verbindingstijden van 50 ms naar 5 ms worden teruggebracht) en snelheidsbeperking op applicatie-, proxy- en queryniveau. Isolatie van de werkbelasting leidt verkeer met lage en hoge prioriteit naar afzonderlijke instanties, zodat nieuwe, minder geoptimaliseerde functies de kernservices niet kunnen 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. OpenAI ontdekte echter dat één door ORM gegenereerde zoekopdracht die twaalf tabellen combineerde, 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 naar voren komen. Maak het doornemen van deze vragen tot een standaardpraktijk.
Implementeer een strikte operationele discipline. OpenAI staat alleen lichte schemawijzigingen toe; alles wat een volledige tabelherschrijving activeert, is verboden. Schemawijzigingen hebben een tijdslimiet van 5 seconden. Langdurige zoekopdrachten worden automatisch gestopt om te voorkomen dat databaseonderhoudsbewerkingen worden geblokkeerd. Bij het opladen van gegevens hanteren ze zeer agressieve snelheidslimieten, waardoor de operatie meer dan een week kan duren.
Leesintensieve workloads met burst-writes kunnen langer op een enkele PostgreSQL-primary draaien dan vaak wordt gedacht. De beslissing om te sharden moet afhangen van werklastpatronen, niet van het aantal gebruikers.
Deze aanpak is vooral relevant voor AI-toepassingen, die vaak leesgerichte werklasten hebben met onvoorspelbare verkeerspieken. Deze kenmerken komen overeen met het patroon waarin een enkele primaire PostgreSQL effectief kan schalen.
De geleerde lessen zijn duidelijk: identificeer echte knelpunten, optimaliseer de bewezen infrastructuur waar mogelijk en migreer selectief wanneer dat nodig is. Een volledige herinrichting van de architectuur is niet altijd het antwoord op de schaaluitdagingen.
