The Pulse

OpenAI svela Habitat, il sistema di archiviazione al servizio di 1 miliardo di utenti settimanali

OpenAI afferma che la sua piattaforma di archiviazione Habitat serve oggi prodotti utilizzati da più di 1 miliardo di persone ogni settimana. Il sistema gestisce oltre 70 milioni di richieste al secondo e conserva più di 500 petabyte di dat

AI.info Team · 2026-09-12

Più di 70 milioni di richieste di accesso ai dati al secondo passano oggi attraverso un sistema che OpenAI ha costruito per supportare prodotti utilizzati da oltre 1 miliardo di persone ogni settimana. L’azienda ha reso noti i dati l’11 settembre 2026, in un articolo tecnico dedicato a Habitat, una piattaforma di archiviazione interna cresciuta da una piccola libreria Python fino a diventare un sistema distribuito che gestisce più di 500 petabyte di dati.

Habitat è alla base di ChatGPT, Codex, dell’API di OpenAI e dei servizi interni. Si occupa delle operazioni meno visibili necessarie prima che un prodotto possa rispondere: individuare i dati, verificare le autorizzazioni, scegliere una regione in cui conservarli, gestire la cifratura, instradare le richieste e decidere quando usare una cache invece di un database.

Le informazioni diffuse offrono uno sguardo raro sull’infrastruttura applicativa che sostiene la crescita degli utenti di OpenAI. L’azienda afferma che Habitat opera in quasi 40 regioni geografiche, mentre i suoi prodotti raggiungono più di 1 miliardo di utenti settimanali. Nell’articolo OpenAI non fornisce una verifica indipendente di quest’ultima cifra: è una misurazione dell’azienda stessa.

Habitat è nato come libreria Python per i GPT

OpenAI ha lanciato Habitat durante il suo evento DevDay nel 2023 per supportare i GPT personalizzati. La prima versione era una piccola libreria client Python collegata al server principale di ChatGPT e basata su Azure Cosmos DB. Gli ingegneri dei team di prodotto potevano usarla per archiviare e recuperare dati senza dover gestire direttamente l’instradamento verso i database, i dettagli degli schemi o i controlli degli accessi.

La scelta progettuale rispondeva a un problema pratico all’interno di OpenAI: ogni team di prodotto aveva bisogno di archiviare dati, ma pochi avrebbero dovuto conoscere il funzionamento del sistema di database sottostante. Habitat offriva un’interfaccia circoscritta, assumendosi la responsabilità di instradare le richieste verso Azure Cosmos DB, le cache e altre risorse di archiviazione.

Gli ingegneri di OpenAI scrivono che ogni normale azione dell’utente può richiedere molte consultazioni distinte dei dati. Accedere al proprio account, aprire una conversazione, controllare le impostazioni di Codex o caricare una funzionalità possono comportare più operazioni di lettura. Una consultazione lenta o non riuscita può quindi compromettere l’intera esperienza dell’utente, anziché una singola funzione isolata.

«Se queste richieste sono lente, il prodotto sembra lento.»

Jon Lee, membro del personale tecnico di OpenAI

Con l’adozione della libreria da parte di un numero crescente di team, Habitat ha acquisito funzionalità per la gestione delle cache, la compressione, la cifratura e altre funzioni della piattaforma. Secondo OpenAI, a metà del 2025 il modello basato sul client aveva raggiunto i propri limiti. Il numero di servizi era aumentato e apportare modifiche compatibili con le versioni precedenti a una libreria condivisa era diventato sempre più difficile.

OpenAI ha trasformato Habitat in un servizio centralizzato

OpenAI ha reagito trasformando Habitat in un servizio autonomo. Il cambiamento ha dato all’azienda un unico punto da cui distribuire gli aggiornamenti, osservare il traffico e applicare controlli a tutta la piattaforma. Anziché distribuire la logica di archiviazione tra i singoli prodotti, OpenAI poteva apportare una modifica a livello centrale e renderla disponibile a tutti i servizi che usano Habitat.

Il servizio è diventato anche un punto centrale per l’applicazione dei controlli sui dati. OpenAI afferma che Habitat applica le politiche di controllo degli accessi, registra i log di audit e limita l’accesso a risorse sottostanti come Azure Cosmos DB. Il sistema supporta inoltre le decisioni sulla residenza dei dati, la cifratura, l’isolamento dei tenant, la regolazione delle richieste e i limiti alla loro frequenza.

Questa centralizzazione è importante perché i prodotti di OpenAI non hanno tutti lo stesso carico di lavoro. Le conversazioni di ChatGPT, la configurazione di Codex, i servizi API e gli strumenti interni possono generare schemi diversi di lettura e scrittura. Il compito di Habitat è fornire un livello di controllo comune senza costringere ogni team di prodotto a risolvere autonomamente gli stessi problemi di archiviazione.

Durante la prima grande fase di espansione, l’azienda ha mantenuto il servizio in Python, pur riconoscendo che il linguaggio comportava costi a volumi di traffico elevati. Secondo OpenAI, la decisione è stata deliberata: la priorità immediata era stabilizzare la piattaforma e offrire agli sviluppatori dei prodotti un’interfaccia uniforme, non ridurre fin dall’inizio ogni singola unità di consumo di CPU e memoria.

Python ha portato Habitat oltre 20 milioni di richieste al secondo

Gestire un servizio ad alto volume di traffico in Python poneva un problema specifico di prestazioni. Habitat usava operazioni di input/output asincrone per gestire contemporaneamente molte richieste di rete, ma l’esecuzione asincrona non consentiva di elaborare in parallelo le operazioni che impegnano la CPU. Instradamento, compressione, cifratura, checksum, verifiche dello stato del sistema e altre attività potevano occupare l’event loop mentre le risposte attendevano di essere elaborate.

OpenAI ha iniziato a misurare il tempo che trascorreva tra la pianificazione delle attività in background e la loro effettiva esecuzione. Quando l’utilizzo era elevato, il ritardo poteva raggiungere centinaia di millisecondi e, in alcuni casi, diversi secondi. Il team ha reagito limitando il numero di richieste contemporanee gestite da ciascun processo e aumentando il numero dei processi worker.

Un problema di prestazioni dipendeva dalla configurazione dei flag delle funzionalità. OpenAI ha scoperto che tutti i worker di un pod potevano interrompersi più o meno nello stesso momento per analizzare un grande file di configurazione. Gli ingegneri hanno ridotto le dimensioni della configurazione, allungato l’intervallo tra gli aggiornamenti e introdotto variazioni nei tempi, così che i worker non eseguissero tutti contemporaneamente la stessa operazione onerosa.

La gestione del pool di connessioni creava un’altra modalità di guasto. OpenAI ha scoperto che il meccanismo predefinito di riutilizzo delle connessioni secondo l’ordine «ultimo entrato, primo uscito» nello stack di rete di Python poteva indirizzare il nuovo traffico verso processi già sovraccarichi. L’effetto poteva concentrare le richieste sui worker lenti e prolungare il peggioramento delle prestazioni anche dopo la fine del picco iniziale.

Oggi l’azienda si affida principalmente a Istio ed Envoy per la gestione del pool di connessioni e il bilanciamento del carico che tiene conto dello stato dei server. Envoy consente inoltre a OpenAI di condividere le connessioni HTTP/2 tra più flussi di traffico, ridurre il sovraccarico dovuto alle connessioni e collocare in un livello centrale i limiti alla frequenza delle richieste e i meccanismi di interruzione automatica.

Codex e GPT-5.5 hanno contribuito alla riscrittura del servizio in Rust

Alla fine OpenAI ha trasferito l’implementazione del servizio Habitat a Rust. L’azienda afferma che due ingegneri hanno completato la riscrittura nel secondo trimestre del 2026 con l’assistenza di Codex e GPT-5.5. La versione in Rust gestisce oggi il 95% delle richieste in produzione, mentre OpenAI prevede di ritirare l’implementazione in Python nelle prossime settimane.

OpenAI riferisce che, rispetto alla versione in Python, il servizio in Rust è sei volte più efficiente nell’uso della CPU e 15 volte più efficiente nell’uso della memoria. L’azienda afferma inoltre che la riscrittura ha ridotto la latenza media e quella dei casi più lenti, anche se l’articolo non fornisce una tabella dettagliata dei benchmark né indica le condizioni di carico alla base di questi confronti.

La migrazione è arrivata dopo che Python aveva già permesso a Habitat di superare i 20 milioni di richieste al secondo nei momenti di picco. La cifra illustra il compromesso ingegneristico scelto da OpenAI: la prima versione non doveva necessariamente essere quella definitiva, se poteva offrire ai team di prodotto una piattaforma stabile mentre l’azienda affrontava problemi di scalabilità più urgenti.

Secondo OpenAI, anche l’API limitata di Habitat ha aiutato il sistema a crescere. I client non possono inviare query SQL arbitrarie che potrebbero comportare la scansione di grandi tabelle o join complessi. Habitat offre invece un’interfaccia più semplice, in stile NoSQL, per la normale archiviazione online, mentre Rockset gestisce i carichi di lavoro che richiedono query analitiche o di ricerca più complesse.

Azure Cosmos DB resta uno dei principali livelli di archiviazione

Habitat non è di per sé un singolo database. Coordina diversi sistemi, tra cui Azure Cosmos DB, Nanobase, le cache Valkey, il blob storage e i servizi di acquisizione delle modifiche ai dati. La piattaforma decide come instradare una richiesta e quale risorsa di archiviazione debba gestirla.

Azure Cosmos DB svolge un ruolo importante nell’architettura. Gli ingegneri di OpenAI lo descrivono come il database applicativo su cui si basava la prima libreria Habitat e affermano che l’azienda ha continuato a migrare i carichi di lavoro con molte operazioni di scrittura e adatti alla suddivisione in shard verso sistemi come Cosmos DB. L’obiettivo è tenere le scritture ad alto volume lontane dall’installazione PostgreSQL primaria dell’azienda.

OpenAI ha comunicato separatamente, nel gennaio 2026, che PostgreSQL continua a supportare i carichi di lavoro fondamentali di ChatGPT e dell’API. Il sistema usa un’unica istanza primaria di Azure PostgreSQL flexible server e quasi 50 repliche di lettura distribuite in più regioni. Secondo OpenAI, PostgreSQL gestisce milioni di query al secondo per i carichi di lavoro in cui prevalgono le letture, mentre i sistemi suddivisi in shard si occupano dei carichi più difficili da gestire per un singolo database primario.

Le due comunicazioni tecniche descrivono livelli complementari, non la sostituzione di uno con l’altro. PostgreSQL continua a gestire dati applicativi già esistenti, mentre Habitat fornisce un’interfaccia di archiviazione comune a diversi sistemi e ai prodotti più recenti. Ne risulta un’architettura deliberatamente mista, anziché un unico database destinato a gestire ogni tipo di richiesta.

Il prossimo vincolo sono i dati, non solo il traffico

OpenAI afferma che il sistema Habitat attuale elabora più di 70 milioni di richieste al secondo e conserva più di 500 petabyte di dati. Queste cifre creano problemi operativi che vanno oltre la sola capacità di gestire il volume del traffico. La collocazione dei dati, le regole sulla loro residenza, le autorizzazioni, la cifratura, il comportamento delle cache e l’isolamento dei tenant devono funzionare in tutte le regioni e per tutti i prodotti.

Il prossimo articolo tecnico dell’azienda si concentrerà sul livello di archiviazione vero e proprio. OpenAI afferma che intende spiegare come Habitat gestisca più di 500 petabyte e oltre 70 milioni di richieste al secondo, trattando anche il lavoro svolto con Azure Cosmos DB. Il primo articolo lascia aperte diverse domande, tra cui la distribuzione geografica dei dati, la quota conservata nelle cache e il costo dell’archiviazione necessaria a supportare la base di utenti.

Le informazioni diffuse da OpenAI mostrano anche quanto rapidamente possano ampliarsi le responsabilità di una piattaforma interna. Habitat è nato nel 2023 come libreria pensata per semplificare il lavoro con i GPT personalizzati. Tre anni dopo è diventato un servizio globale che collega prodotti per i consumatori, strumenti per gli sviluppatori e sistemi interni a diverse tecnologie di archiviazione.

La misura concreta di questa crescita non è il nome della piattaforma, ma il carico di lavoro che oggi sostiene: più di 70 milioni di richieste al secondo, oltre 500 petabyte di dati e prodotti utilizzati da più di 1 miliardo di persone ogni settimana. OpenAI afferma che la prossima parte della serie spiegherà come il livello dei database venga spinto a gestire questi volumi.