Nel cuore dell’infrastruttura tecnologica che sostiene ChatGPT e le API di OpenAI c’è un elemento che forse sorprende chi non vive nel mondo dei sistemi distribuiti: non un database nuovo o esotico, non una soluzione database mesh o blockchain, ma uno dei più solidi e consolidati database relazionali al mondo, PostgreSQL. Quella che per molti anni è stata la scelta classica per applicazioni aziendali di medie dimensioni è diventata, con un’opportuna ingegnerizzazione e ottimizzazione, il componente centrale di una piattaforma utilizzata da circa 800 milioni di utenti in tutto il mondo e capace di gestire milioni di query al secondo. La storia recente di come OpenAI sia arrivata a questo risultato offre uno sguardo affascinante su come si possano estendere i limiti di tecnologie ritenute consolidate e su quali compromessi e soluzioni ingegneristiche ciò richieda.
Per anni PostgreSQL è stato uno dei sistemi più affidabili e ricchi di funzionalità nel mondo open source, apprezzato per la sua conformità agli standard SQL, l’ampiezza di strumenti e la solidità complessiva. OpenAI lo ha adottato sin dalle prime versioni di ChatGPT per gestire i dati operativi — profili utente, stato delle sessioni, log e altre informazioni critiche — e con la crescita esponenziale della piattaforma il carico sui database è aumentato di oltre dieci volte nell’ultimo anno. Per affrontare questa crescita, gli ingegneri di OpenAI hanno affrontato alcune delle limitazioni intrinseche di PostgreSQL e delle architetture di database tradizionali, mettendo in campo una combinazione di strategie che hanno permesso di tenere insieme performance, affidabilità e semplicità operativa.
Una delle scelte più controverse e al tempo stesso più efficaci è stata quella di mantenere un’architettura “single primary” per gli scritti, cioè una singola istanza primaria di PostgreSQL che gestisce tutte le operazioni di scrittura. In molti modelli moderni di database a scala elevata si adotta lo sharding, ovvero la suddivisione dei dati in porzioni distribuite su più nodi, oppure si passa a database distribuiti progettati fin dall’inizio per gestire carichi massivi. Queste soluzioni, pur potenti, introducono una complessità operativa enorme: richiedono di riscrivere parti consistenti dell’applicazione, di gestire transazioni distribuite e di mantenere una coordinazione coherente tra nodi. In OpenAI queste soluzioni sono state valutate, ma considerate troppo costose in termini di tempo e rischio: ridisegnare centinaia di endpoint applicativi per supportare lo sharding avrebbe potuto impegnare ingegneri per mesi o anni.
La strategia adottata, invece, si basa su una profonda ottimizzazione di PostgreSQL per i carichi di lavoro read-heavy (cioè prevalentemente costituiti da letture di dati) che caratterizzano la maggior parte delle richieste di ChatGPT. OpenAI infatti ha distribuito circa 50 repliche di sola lettura, geograficamente collocate per servire le richieste degli utenti più vicini possibile, mentre la singola istanza primaria si concentra sui compiti di scrittura più critici. Questa struttura permette di scalare le operazioni di lettura senza frammentare i dati stessi, minimizzando la latenza e mantenendo un’elevata disponibilità.
Ovviamente questa scelta non è stata indolore, perché PostgreSQL non è stato originariamente progettato per sostenere carichi di scrittura estremamente elevati su un’unica istanza. La sua gestione delle transazioni — basata sul Multiversion Concurrency Control (MVCC) — garantisce isolamento e coerenza, ma crea sovraccarico quando si aggiornano righe frequentemente, costringendo il sistema a mantenere più versioni dello stesso dato e a svolgere operazioni di manutenzione complesse. Per questo motivo OpenAI ha deciso di spostare progressivamente i carichi di lavoro più intensivi in scrittura su sistemi sharded specifici, come Azure Cosmos DB, lasciando in PostgreSQL solo le operazioni che si prestano bene all’approccio single primary with read replicas.
Ma le ottimizzazioni non si sono limitate alla semplice distribuzione del carico. OpenAI ha introdotto meccanismi di pooling delle connessioni per ridurre i tempi di setup tra applicazioni e database, arrivando a ridurre la latenza di connessione da decine di millisecondi a pochi millisecondi anche sotto carichi estremamente elevati. Sono stati implementati sistemi di cache locking per prevenire il cosiddetto “thundering herd”, ovvero l’effetto in cui molte richieste simultanee causano un sovraccarico uniforme della cache, con conseguente crollo delle prestazioni. Su più livelli dell’architettura sono stati applicati rate limiting, isolamento dei carichi di lavoro e politiche di timeout per query lunghe, con l’obiettivo di proteggere l’integrità del sistema durante picchi improvvisi di traffico.
Un altro aspetto interessante che emerge dalla documentazione tecnica è l’attenzione con cui OpenAI ha monitorato e ottimizzato le query generate da framework di Object-Relational Mapping (ORM). Strumenti come Django o SQLAlchemy facilitano lo sviluppo, ma in produzione possono generare join molto complessi o inefficienze che, amplificate dal volume di traffico, portano a incidenti gravi di saturazione delle risorse. Per questo motivo è diventato prassi consolidata rivedere e ottimizzare tali query, evitando pattern anti-scalabilità e prevenendo che una singola richiesta pesante possa degradare l’intero sistema.
L’esperienza di OpenAI con PostgreSQL offre quindi spunti importanti per molte imprese tecnologiche: mentre la visione dominante nel campo dei sistemi distribuiti spinge verso soluzioni sempre più complesse, la combinazione di un database consolidato con ottimizzazioni puntuali, repliche distribuite e migrazione selettiva dei carichi di lavoro più pesanti può costituire una soluzione pragmatica e meno distruttiva per scalare applicazioni ad altissima domanda. Non è una soluzione “plug-and-play” né adatta a ogni scenario, ma dimostra che, con ingegneria accurata, PostgreSQL può sostenere applicazioni moderne di portata mondiale, gestendo miliardi di query mensili con performance elevate e affidabilità massima.
In un momento in cui molte aziende stanno ripensando le loro architetture dati per abbracciare l’era dell’intelligenza artificiale, la storia di OpenAI rivela che non sempre è necessario abbandonare tecnologie consolidate per ottenere prestazioni hyperscale: a volte, con le giuste strategie e un’attenta disciplina operativa, anche un “vecchio” database relazionale può dare risultati straordinari