Como a OpenAI escalou o Habitat de biblioteca Python a plataforma de storage para 1 bilhão de usuários

A OpenAI publicou no próprio blog de engenharia, em setembro de 2026, a primeira parte de uma série técnica sobre como construiu o Habitat, a camada de storage online que sustenta ChatGPT e outros produtos da empresa. O post é o primeiro de uma série de duas partes sobre como escalaram o storage online, contando como o Habitat evoluiu, por que viraram uma biblioteca em serviço, e como esticaram um serviço escrito em uma linguagem incomum para stack de serving (Python) numa camada de storage confiável. A segunda parte promete detalhar multi-tenancy, otimização de leitura em camadas e a parceria com Azure Cosmos DB.

Antes de entrar no mecanismo, uma nota sobre um número. Circula publicamente a cifra de 22 milhões de requests por segundo, mas o próprio artigo da OpenAI cita outro valor: o Habitat hoje lida com mais de 70 milhões de requests por segundo, dando suporte a produtos usados por mais de 1 bilhão de pessoas por semana, em quase 40 regiões geográficas. Vou usar o número do artigo. A divergência provavelmente reflete revisões durante a publicação, mas registro aqui porque quem vier atrás do dado vai encontrar as duas versões.

O fato, em uma frase

A OpenAI construiu uma camada de storage própria chamada Habitat, começou como biblioteca Python client-side em 2024, e em cerca de dois anos virou um sistema distribuído sobre Azure Cosmos DB que serve mais de 500 petabytes de dados para produtos com escala de bilhão de usuários semanais.

Como o Habitat funciona por baixo

De biblioteca client-side para serviço

O ponto de partida é importante porque explica quase todas as decisões seguintes. A ideia inicial era simples: engenheiros de produto não deveriam precisar pensar em gerenciamento de banco de dados. O Habitat começou em meados de 2024 como uma pequena biblioteca Python que interagia com o servidor principal do ChatGPT. O trabalho da biblioteca era dar aos times de produto uma forma simples de armazenar e recuperar dados sem precisar dominar os detalhes por baixo.

Isso é o padrão clássico de biblioteca de acesso a dados: você importa, chama get, put, query, e a biblioteca traduz para o banco. No caso, a biblioteca suportava um pequeno conjunto de operações que mapeavam por baixo para a aplicação de banco de dados, Azure Cosmos DB.

Uma biblioteca client-side tem duas vantagens: latência baixa (não tem hop extra de rede) e simplicidade operacional (não tem servidor para escalar). E duas fraquezas grandes quando o produto cresce:

• Toda mudança na biblioteca exige que cada serviço-cliente faça deploy de nova versão. Corrigir um bug de acesso a dados vira uma coordenação com N times.
• Não dá para controlar centralmente coisas como rate limiting por tenant, circuit breaker, cache compartilhado ou roteamento inteligente entre regiões. Cada processo do cliente tem sua própria visão do mundo.

Por isso a OpenAI descreve a transição para serviço como necessária. O Habitat teve que crescer com a empresa: primeiro se tornando confiável o suficiente para tráfego de produto crítico, depois rápido o suficiente para usuários globais, e por fim, operando com destreza em escala massiva. Cada uma dessas três fases resolve um problema diferente, e a ordem importa: não adianta ser rápido se não é confiável, e não adianta ser rápido e confiável se não escala.

Por que Python num caminho de serving?

Esse é o detalhe mais estranho do anúncio, e o que a própria OpenAI reconhece como incomum. A ideia foi esticar um serviço escrito em uma linguagem incomum para stack de serving, Python, em uma camada de storage confiável.

Storage layers de alta throughput em geral são escritas em Go, Rust, Java ou C++, por razões óbvias: GIL, custo de contexto, latência de garbage collector, e por aí vai. Python num serviço que lida com dezenas de milhões de requests por segundo é uma escolha que exige justificativa, e a Parte 1 do post promete tratar disso. O que dá para especular com segurança: se a biblioteca original já era Python (porque o resto do stack de aplicação da OpenAI é Python), transformar em serviço em Python evita reescrita e mantém o mesmo modelo mental para os times de produto. O custo é ter que investir pesado em async, pooling e provavelmente em partes críticas escritas em extensões nativas. Mas isso é hipótese, o post público não confirma esse raciocínio.

Onde entra o Azure Cosmos DB

O Habitat não é um banco. É a camada acima do banco. O banco é o Azure Cosmos DB, e a Microsoft confirmou publicamente essa parceria em outubro de 2025 no anúncio do SDK Python 4.14.0 do Cosmos DB. Muitas das features desse SDK foram desenvolvidas em parceria próxima com a OpenAI, que depende bastante do Cosmos DB para armazenar dados de chat do ChatGPT em escala massiva. Foi uma release estável que combina performance, inteligência e produtividade de desenvolvedor, com features provadas em cenários reais, incluindo alguns dos workloads de IA mais exigentes do mundo.

Muitas otimizações foram desenvolvidas enquanto suportavam os pipelines massivos de dados da OpenAI, garantindo que o SDK seja capaz de sustentar as demandas de IA generativa e workloads semânticos em tempo real. Ou seja, o Habitat empurrou tanto o Cosmos DB que o próprio SDK evoluiu por causa dele. Esse é o tipo de coisa que só acontece quando o cliente é grande demais para ser tratado como cliente comum.

O que isso significa na prática

Se você está construindo algo do zero, o padrão é útil mesmo em escala muito menor. A ideia central é: coloque uma camada fina entre o seu código de produto e o seu banco, e faça essa camada ser sua. No começo é uma biblioteca, depois pode virar serviço.

Um esqueleto mínimo em Python, só para dar concretude:

class Habitat:
 def __init__(self, backend):
 self._backend = backend # cliente Cosmos, Postgres, o que for

 async def get(self, namespace: str, key: str):
 # ponto único para adicionar cache, métricas, retry, rate limit
 return await self._backend.read(namespace, key)

 async def put(self, namespace: str, key: str, value: dict):
 # ponto único para validação, auditoria, replicação
 return await self._backend.write(namespace, key, value)

O ponto não é o código. É que get e put passam por um único choke point. Quando amanhã você precisa adicionar cache regional, circuit breaker por tenant, ou trocar de banco atrás dos panos, você tem um lugar para mexer. Se cada serviço fala com o banco direto, você não tem esse lugar.

A transição de biblioteca para serviço se justifica quando:

• Você tem múltiplos times consumindo, e coordenar upgrade de biblioteca vira gargalo.
• Você quer aplicar políticas globais (quota, prioridade, roteamento) que exigem visão agregada do tráfego.
• Você precisa fazer connection pooling agressivo com o banco, e ter N clientes abrindo conexões independentes vira problema.

Onde isso quebra ou não vale a pena

Vamos ser específicos sobre o que não é bom no modelo Habitat, tanto em geral quanto na versão da OpenAI:

• Latência. Colocar um serviço entre a aplicação e o banco adiciona pelo menos um hop de rede. Em cargas onde a latência interna do banco é 1 a 2 ms, adicionar 1 ms de proxy é 50 a 100 por cento a mais. Só vale se o que a camada faz (cache, roteamento, batching) compensa esse custo.
• Ponto único de falha. Se o Habitat cai, tudo cai. A OpenAI descreve isso indiretamente ao dizer que se os requests são lentos, o produto parece lento, e se os requests falham, o produto para de funcionar por completo. É um problema resolvível (replicação, multi-região) mas caro.
• Python em hot path. A menos que você tenha equipe para lidar com async, uvloop, extensões em C ou Rust, e profiling contínuo, não é recomendável copiar essa parte. A OpenAI conseguiu porque tem gente dedicada só para isso. Numa startup pequena, Go ou Rust dá menos dor de cabeça.
• Custo. 500 petabytes em Cosmos DB globalmente distribuído não é barato. O modelo faz sentido para quem tem produto com margem para pagar. Para um SaaS B2B pequeno, Postgres gerenciado resolve por dois ou três anos sem esse tipo de abstração.

O que não dá para afirmar ainda

Alguns pontos não estão esclarecidos na publicação atual, porque o artigo é a Parte 1:

• O mecanismo interno de como o Habitat faz sharding, replicação ou consistência não está detalhado. A parte técnica pesada foi prometida para a Parte 2, que segundo o próprio post vai cobrir confiabilidade de multi-tenancy em escala, a estratégia em camadas para otimizar performance de leitura, e como escalaram a parceria com Azure Cosmos DB para lidar com demanda sem precedentes.
• A escolha de continuar em Python no serving layer é mencionada mas não justificada em profundidade no post público. A leitura sobre reuso de código e produtividade é hipótese, não fato confirmado.
• Não há benchmarks públicos comparando o Habitat com alternativas (por exemplo, cliente Cosmos direto, ou proxies como Envoy com plugins). Não dá para afirmar que a abordagem é ótima em termos de custo por request.
• Discrepância nos números: 22M req/s em referências públicas versus 70M req/s no corpo do artigo. Não está claro se um é histórico e outro atual, ou se houve revisão. Ficam registrados os dois.
• O Habitat não é open source. Tudo que se pode dizer vem do que a OpenAI e a Microsoft publicaram, mais conhecimento genérico sobre padrões de storage.

Como testar isso você mesmo

Você não vai rodar o Habitat, mas dá para reproduzir o padrão em pequena escala e sentir onde ele começa a fazer sentido. Um exercício de uma tarde:

1. Escolha um projeto seu que fala direto com Postgres, Mongo ou similar.
2. Crie um módulo storage.py com uma classe que exponha só get, put, query, cada um recebendo namespace e key. Substitua todas as chamadas diretas ao banco por chamadas a essa classe.
3. Adicione logging estruturado dentro do módulo, contando requests por namespace, latência p50 e p99, e taxa de erro.
4. Rode em produção (ou staging com tráfego real) por uma semana. Olhe o que você aprende sobre o próprio produto. Provavelmente vai descobrir que 80 por cento do tráfego é em 3 ou 4 padrões de acesso, e que dá para cachear grande parte disso trivialmente.
5. Só depois disso, se fizer sentido, considere transformar o módulo em serviço HTTP ou gRPC separado. Se não fizer sentido, você ganhou observabilidade e um choke point de graça.

Esse é o valor prático da história do Habitat, independente da escala da OpenAI: a camada de storage própria não começa como plataforma distribuída. Começa como uma classe. O resto é consequência de sobreviver ao crescimento.