OpenAI e la scommessa su PostgreSQL: genio o azzardo?

Anita Innocenti

Le regole del digitale stanno cambiando.

O sei visibile o sei fuori. Noi ti aiutiamo a raggiungere i clienti giusti — quando ti stanno cercando.

Contattaci ora →

Tra PostgreSQL e Azure Cosmos DB, la strategia di OpenAI per domare i Big Data si scontra con ritardi miliardari e un incidente che ha messo a dura prova l’intero sistema

OpenAI sceglie il veterano PostgreSQL per gestire gli 800 milioni di utenti di ChatGPT, una mossa audace basata su un'architettura software ingegnosa. Tuttavia, questa facciata di efficienza nasconde una profonda fragilità: i ritardi miliardari nel progetto Stargate e le inadempienze di Microsoft espongono il sistema a rischi enormi.

OpenAI e la scommessa su PostgreSQL: genio o azzardo da 800 milioni di utenti?

Mentre tutti corrono verso soluzioni avveniristiche e database proprietari costosissimi, OpenAI fa una mossa che, diciamocelo, lascia un po’ spiazzati.

Per gestire il traffico mostruoso di ChatGPT, con oltre 800 milioni di utenti che generano milioni di richieste al secondo, ha deciso di puntare su un cavallo di razza, sì, ma non esattamente di primo pelo: PostgreSQL, un sistema open-source.

Una scelta controcorrente che dimostra come un’infrastruttura considerata “tradizionale” possa, se ben orchestrata, reggere carichi di lavoro che farebbero impallidire molti sistemi moderni.

Ma come ci sono riusciti?

E soprattutto, qual è il vero prezzo da pagare dietro questa facciata di efficienza?

L’architettura “vecchia scuola” che regge l’urto

Il problema fondamentale di un database come PostgreSQL, quando si parla di dimensioni simili, è che non è nato per gestire un’enorme quantità di operazioni di scrittura contemporaneamente. Il vero mal di testa per gli ingegneri di OpenAI, quindi, non era tanto far leggere i dati a milioni di persone, ma evitare che i picchi di scrittura mandassero in tilt il sistema.

La soluzione, come descritto in un loro post tecnico, è stata un mix di astuzia e pragmatismo. Invece di un’unica, gigantesca macchina, hanno usato un server principale Azure PostgreSQL affiancato da quasi 50 “cloni” sparsi per il mondo (le cosiddette repliche di lettura). In questo modo, la maggior parte del traffico di lettura viene deviato su queste copie, lasciando respirare il server primario.

Per le operazioni più pesanti e che richiedono molta scrittura, la strategia è stata ancora più drastica: sono state letteralmente “sfrattate” su altri sistemi, come Azure Cosmos DB. Hanno anche messo un “filtro” intelligente, una cache, che intercetta le richieste più comuni prima ancora che raggiungano il database.

E per i nuovi progetti?

Regola ferrea: nessuna nuova tabella su PostgreSQL.

Chi ha bisogno di spazio, deve usare sistemi già pensati per essere frammentati e distribuiti.

Una soluzione ingegnosa, non c’è che dire.

Peccato che l’ingegneria software da sola non basti quando l’hardware inizia a scricchiolare.

I miliardi di Stargate e le promesse mancate di Microsoft

Ed è qui che la storia si fa interessante, perché dietro la brillante soluzione software si nasconde una realtà infrastrutturale molto più precaria. Come riportato su The Information, OpenAI ha impegnato circa 19 miliardi di dollari nel progetto del data center Stargate in Texas.

Una cifra da capogiro, che però si scontra con ritardi costruttivi e una fornitura di hardware che definire lenta è un eufemismo. La fame di potenza di calcolo di OpenAI è tale che nemmeno un colosso come Microsoft, il suo partner principale, riesce a starle dietro.

Pare che già a ottobre 2024 in OpenAI abbiano perso la pazienza con Microsoft, accusandola di non muoversi abbastanza in fretta nel fornire i server necessari. Il data center di Stargate, che doveva essere la soluzione, arranca, con una frazione della capacità promessa che sarà disponibile a fine 2026.

Stiamo parlando di un castello tecnologico all’avanguardia costruito su fondamenta che sembrano tutt’altro che solide.

Questa tensione tra software brillante e hardware zoppicante ha già mostrato le sue crepe più profonde.

L’incidente che ha quasi mandato tutto in tilt

Ti ricordi il lancio virale di Sora?

Quel successo si è trasformato nell’unico incidente di massima gravità registrato da OpenAI negli ultimi 12 mesi, un segnale inequivocabile di quanto il sistema sia vulnerabile a picchi di crescita estremi.

Un evento del genere dimostra che, per quanto ottimizzata, l’architettura resta appesa a un filo sottilissimo.

Certo, stanno già lavorando a nuove soluzioni, come una sorta di “catena di Sant’Antonio” per le repliche (la cascading replication), che permetterebbe di scalare ulteriormente senza sovraccaricare il server principale.

Ma la domanda resta: questa complessa impalcatura, sostenuta da investimenti miliardari e partnership tese, è davvero un modello sostenibile o solo un modo incredibilmente costoso per tenere in piedi un gigante che cresce più in fretta di quanto il mondo reale possa supportare?

Anita Innocenti

Sono una copywriter appassionata di search marketing. Scrivo testi pensati per farsi trovare, ma soprattutto per farsi scegliere. Le parole sono il mio strumento per trasformare ricerche in risultati.

8 commenti su “OpenAI e la scommessa su PostgreSQL: genio o azzardo?”

  1. La mossa tecnica è fumo negli occhi per nascondere che dipendono da un partner inaffidabile, una sensazione che purtroppo mi è fin troppo familiare.

  2. Luciano D’Angelo

    L’attenzione sulla scelta tecnica mi pare un diversivo. È l’unica decisione logica in un progetto con fondamenta fragili e promesse mancate. La vera debolezza, per me, resta l’infrastruttura sottostante.

    1. Luciano, si discute del motore di una fuoriserie montato su un telaio di cartone, elogiandone la potenza mentre le fondamenta scricchiolano. Non so se ammirare il pragmatismo o temere il crollo imminente.

  3. Melissa Benedetti

    Scelta tecnica solida, il resto fuffa. Si parla di big data, ma la gestione è da startup. A volte penso che il mio funnel di conversione sia più stabile di ‘sto baraccone.

  4. Gabriele Caruso

    La scelta tecnica è fumo negli occhi. Si nasconde la fragilità strutturale dietro il paravento dell’open source. Una narrazione ben costruita per noi sognatori digitali. Ma quando crolla il castello di carte, chi paga il conto?

  5. La scelta di PostgreSQL è l’unica cosa sensata, il resto è il solito teatrino di giganti che bruciano miliardi per la propria inettitudine. Alla fine, il conto di questa fragilità lo pagheranno solo gli utenti.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Ricevi i migliori aggiornamenti di settore