OpenAI detalha como escalou o Azure Cosmos DB no Habitat para atender mais de 1 bilhão de usuários do ChatGPT

O texto da OpenAI conta a Parte II da história do Habitat, a plataforma de armazenamento que atende mais de 1 bilhão de usuários em 40 regiões, com mais de 500 petabytes. O foco é o Azure Cosmos DB por baixo. A empresa passou por três fases: um único container multi-tenant, depois containers single-tenant dedicados, e por fim um container multi-tenant por padrão.

O problema técnico central está nos limites. O limite documentado de 10K RU/s por chave de partição lógica, na prática, é imposto na partição física, então chaves vizinhas competem pelo mesmo teto. Além disso, quando a partição física se divide com o crescimento dos dados, o throughput efetivo por partição cai, mesmo com o tráfego estável. Os containers dedicados resolveram o isolamento, mas exigiram pré-provisionamento em cada lançamento, e times esqueciam de escalar antes do dia D. A volta ao multi-tenant veio com ajustes feitos junto ao time do Azure: throttling das chaves mais quentes, QoS com priorização de requisições (cargas offline como inserções em massa e extrações são limitadas primeiro) e um modo serverless novo, com partições escalando até 10K RU/s e splits por uso de RU, além de por armazenamento. Segundo a OpenAI, não houve incidentes de provisionamento ou noisy neighbor nos meses seguintes.

Em 15 de setembro de 2026, o CEVIU noticiou "Habitat da OpenAI: do Python ao Rust, um salto para bilhões de usuários e 70 milhões de requisições por segundo", sobre a camada de serviço e os mais de 500 petabytes. Agora a atenção se volta para o armazenamento subjacente: a Parte II detalha o Azure Cosmos DB, a migração entre modelos de tenancy e a parceria com o Azure, que não aparecia naquele recorte.

Para quem opera banco de dados em escala, a leitura é que isolamento total por container parece seguro, mas transfere o planejamento de capacidade para todos os times de produto. Centralizar com throttling e priorização de requisições tende a custar menos organizacionalmente. Também fica o recado de que, em volume extremo, serviço gerenciado exige engenharia conjunta com o provedor.