Come OpenAI scala postgresql: la verità dietro l’ia generativa

L’architettura di ChatGPT si basa su PostgreSQL, un database open source degli anni ’80, ma l’ingegneria estrema di OpenAI e Microsoft Azure ha permesso di gestire milioni di query al secondo.

Immaginate per un attimo la scena: milioni di utenti in tutto il mondo che, nello stesso istante, chiedono a ChatGPT di scrivere una mail, correggere un codice Python o spiegare la fisica quantistica.

Dietro quella casella di testo bianca non c’è una magia eterea, ma un’infrastruttura fisica che deve smistare un traffico dati spaventoso senza crollare.

Per anni ci hanno raccontato che per gestire volumi “planetari” servissero database esotici, tecnologie proprietarie complesse o un frazionamento estremo dei dati (lo sharding). E invece, la rivelazione tecnica dell’ultimo anno è tanto sorprendente quanto rassicurante: il motore che spinge l’intelligenza artificiale più famosa al mondo è PostgreSQL. Sì, proprio quel database open source nato negli anni ’80, solido e gratuito, che molti sviluppatori usano per i loro progetti personali.

Ma non fatevi ingannare dalla familiarità del nome. Quello che OpenAI ha costruito sotto il cofano, in tandem con Microsoft Azure, è una lezione di ingegneria estrema che sfida le convenzioni su cosa sia possibile fare con un database relazionale.

Non si tratta solo di installare un software, ma di ripensare radicalmente il modo in cui i dati vengono letti e scritti quando il mondo intero ti sta guardando.

Il mito della frammentazione e la “dittatura” della lettura

Nel mondo dei database su larga scala, la regola aurea è sempre stata “dividi et impera”. Quando il traffico diventa ingestibile, si spezza il database in tanti piccoli pezzi (shards) distribuiti su vari server. È efficace, ma terribilmente complesso da gestire.

OpenAI ha scelto una strada diversa, quasi controcorrente: mantenere un’architettura monolitica per quanto riguarda la scrittura dei dati.

L’idea è audace.

C’è un solo “scrittore” principale (il Primary), colui che detiene la verità assoluta dei dati, e una marea di “lettori” (le Repliche) che distribuiscono questa verità agli utenti. Questo approccio ha permesso a OpenAI di scalare fino a gestire milioni di query al secondo senza la complessità operativa dello sharding. È come avere un solo autore che scrive un libro, ma milioni di tipografie che stampano e distribuiscono le copie in tempo reale.

Se l’autore è veloce e le tipografie sono efficienti, il sistema regge.

Bohan Zhang, membro del team infrastrutturale di OpenAI, ha spiegato chiaramente questa filosofia durante la PGConf.dev, sottolineando come la chiave sia stata ottimizzare il database per un carico di lavoro pesantemente sbilanciato verso la lettura.

In OpenAI, utilizziamo un’architettura non frammentata (unsharded) con un singolo scrittore e molteplici lettori, dimostrando che PostgreSQL può scalare con grazia sotto carichi di lettura massicci.

— Bohan Zhang, Infrastructure Team Member presso OpenAI

Ma come si fa a non far esplodere quell’unico scrittore?

Qui entra in gioco una disciplina quasi militare. OpenAI tratta il nodo primario come una risorsa scarsa e preziosa. Nessuno può scrivere dati se non è strettamente necessario. Le applicazioni sono progettate per filtrare, raggruppare e ottimizzare ogni singola richiesta di scrittura prima che tocchi il database.

È un cambio di paradigma: l’infrastruttura non è più un contenitore infinito dove gettare dati, ma un ecosistema delicato che va protetto dall’inefficienza del codice.

Tuttavia, c’è un dettaglio che spesso sfugge nelle presentazioni trionfali: questo livello di ottimizzazione richiede una partnership profonda con chi ti fornisce i server. E qui entra in scena il gigante di Redmond.

L’infrastruttura a cascata e la simbiosi con Azure

Non si può analizzare il successo di OpenAI senza guardare a chi fornisce il “ferro”. La strategia di scaling adottata non sarebbe stata possibile senza l’introduzione da parte di Microsoft di repliche di lettura a cascata su Azure, una funzionalità che ha permesso di creare una gerarchia di server.

Invece di collegare tutte le repliche di lettura direttamente al nodo primario (rischiando di soffocarlo con il traffico di sincronizzazione), si crea una catena: il primario aggiorna alcune repliche, che a loro volta ne aggiornano altre.

Questo ha permesso di espandere il parco macchine fino a decine di server distribuiti geograficamente, riducendo la latenza per l’utente finale che riceve la risposta dal server più vicino, ovunque si trovi.

È una dimostrazione di forza dell’ecosistema cloud: il software open source fornisce la base, ma l’infrastruttura cloud fornisce i muscoli per portarlo su scala globale.

Un altro eroe silenzioso di questa architettura è PgBouncer, un software che gestisce il pool di connessioni. Immaginate un locale alla moda: se tutti cercassero di entrare dalla porta principale contemporaneamente, si creerebbe il caos. PgBouncer agisce come un buttafuori efficientissimo, mantenendo le connessioni aperte e riutilizzandole, riducendo i tempi di attesa.

I risultati sono tangibili e vanno ben oltre la teoria. L’ottimizzazione del pooling delle connessioni ha abbattuto la latenza da 50ms a meno di 5ms.

Ma è l’affidabilità a colpire davvero: in un settore dove i downtime sono l’incubo di ogni CTO, questo sistema ha mostrato una resilienza notevole.

Dopo tutta l’ottimizzazione che abbiamo fatto, siamo super felici di Postgres in questo momento per i nostri carichi di lavoro pesanti in lettura.

— Bohan Zhang, Infrastructure Team Member presso OpenAI

La felicità degli ingegneri, però, non deve farci dimenticare le sfide nascoste. Una struttura così centralizzata richiede una governance dei dati ferrea. Non si possono fare modifiche allo schema del database (come aggiungere una colonna a una tabella) alla leggera. Ogni cambiamento deve essere chirurgico, asincrono e invisibile all’utente, pena il blocco dell’intero servizio.

È il prezzo da pagare per l’efficienza.

Oltre l’entusiasmo: i rischi della centralizzazione

Se da un lato c’è l’ammirazione per la prodezza tecnica, dall’altro bisogna “unire i puntini” su cosa questo significhi per il futuro. OpenAI ha dimostrato che è possibile scalare PostgreSQL per gestire milioni di query al secondo (dati combinati di lettura e scrittura), ma questo approccio “monolitico” porta con sé dei rischi intrinseci che non vanno sottovalutati.

Affidarsi a un singolo nodo di scrittura (il Primary) crea un collo di bottiglia fisico che, prima o poi, la legge di Moore non riuscirà più a compensare.

Se il traffico di scrittura dovesse esplodere – magari a causa di nuove funzionalità che richiedono la memorizzazione di contesti utente molto più complessi o logiche di ragionamento in tempo reale – l’attuale architettura potrebbe trovarsi con le spalle al muro.

Lo sharding, che oggi è stato evitato con eleganza, potrebbe tornare a bussare alla porta domani con prepotenza.

C’è poi un aspetto di sicurezza e privacy che merita una riflessione critica. Centralizzare così tanti dati e operazioni su un singolo cluster logico semplifica la gestione, ma crea anche un bersaglio di altissimo valore. La resilienza operativa (avere un solo incidente grave in nove mesi è lodevole) non equivale automaticamente alla sicurezza dei dati in caso di compromissione del nodo centrale.

Inoltre, la dipendenza strettissima dalle funzionalità proprietarie di Azure crea un lock-in tecnologico non indifferente: replicare questa architettura altrove non sarebbe un semplice copia-incolla.

In un contesto più ampio, la presentazione di Bohan Zhang ha offerto uno sguardo approfondito su come l’azienda ha portato PostgreSQL a un nuovo livello, ma ha anche implicitamente tracciato una linea di demarcazione.

Esiste un “PostgreSQL per tutti” e un “PostgreSQL per l’Hyperscale”, dove il database open source è solo un componente di un motore molto più vasto e complesso, fatto di cache, bilanciatori di carico e policy aziendali rigide.

La domanda che rimane sospesa non è se questa architettura funzioni oggi – i fatti dimostrano che lo fa eccome – ma quanto a lungo potrà sostenere la crescita esponenziale dell’IA generativa prima che la fisica dei database tradizionali presenti il conto.

Siamo di fronte alla vittoria definitiva del vecchio SQL o solo a una brillante, temporanea, opera di ingegneria per guadagnare tempo?