{"id":706,"date":"2026-09-11T18:34:25","date_gmt":"2026-09-11T21:34:25","guid":{"rendered":"https:\/\/yellowkode.com\/blog\/openai-habitat-storage-python-cosmos-db\/"},"modified":"2026-09-11T18:34:25","modified_gmt":"2026-09-11T21:34:25","slug":"openai-habitat-storage-python-cosmos-db","status":"publish","type":"post","link":"https:\/\/yellowkode.com\/blog\/openai-habitat-storage-python-cosmos-db\/","title":{"rendered":"Como a OpenAI escalou o Habitat de biblioteca Python a plataforma de storage para 1 bilh\u00e3o de usu\u00e1rios"},"content":{"rendered":"

A OpenAI publicou no pr\u00f3prio blog de engenharia, em setembro de 2026, a primeira parte de uma s\u00e9rie t\u00e9cnica sobre como construiu o Habitat<\/strong>, a camada de storage online que sustenta ChatGPT e outros produtos da empresa. O post \u00e9 o primeiro de uma s\u00e9rie de duas partes sobre como escalaram o storage online, contando como o Habitat evoluiu, por que viraram uma biblioteca em servi\u00e7o, e como esticaram um servi\u00e7o escrito em uma linguagem incomum para stack de serving (Python) numa camada de storage confi\u00e1vel. A segunda parte promete detalhar multi-tenancy, otimiza\u00e7\u00e3o de leitura em camadas e a parceria com Azure Cosmos DB.<\/p>\n

Antes de entrar no mecanismo, uma nota sobre um n\u00famero. Circula publicamente a cifra de 22 milh\u00f5es de requests por segundo<\/em>, mas o pr\u00f3prio artigo da OpenAI cita outro valor: o Habitat hoje lida com mais de 70 milh\u00f5es de requests por segundo, dando suporte a produtos usados por mais de 1 bilh\u00e3o de pessoas por semana, em quase 40 regi\u00f5es geogr\u00e1ficas. Vou usar o n\u00famero do artigo. A diverg\u00eancia provavelmente reflete revis\u00f5es durante a publica\u00e7\u00e3o, mas registro aqui porque quem vier atr\u00e1s do dado vai encontrar as duas vers\u00f5es.<\/p>\n

O fato, em uma frase<\/h2>\n

A OpenAI construiu uma camada de storage pr\u00f3pria chamada Habitat, come\u00e7ou como biblioteca Python client-side em 2024, e em cerca de dois anos virou um sistema distribu\u00eddo sobre Azure Cosmos DB que serve mais de 500 petabytes de dados para produtos com escala de bilh\u00e3o de usu\u00e1rios semanais.<\/p>\n

Como o Habitat funciona por baixo<\/h2>\n

De biblioteca client-side para servi\u00e7o<\/h3>\n

O ponto de partida \u00e9 importante porque explica quase todas as decis\u00f5es seguintes. A ideia inicial era simples: engenheiros de produto n\u00e3o deveriam precisar pensar em gerenciamento de banco de dados. O Habitat come\u00e7ou 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.<\/p>\n

Isso \u00e9 o padr\u00e3o cl\u00e1ssico de biblioteca de acesso a dados: voc\u00ea importa, chama get<\/code>, put<\/code>, query<\/code>, e a biblioteca traduz para o banco. No caso, a biblioteca suportava um pequeno conjunto de opera\u00e7\u00f5es que mapeavam por baixo para a aplica\u00e7\u00e3o de banco de dados, Azure Cosmos DB.<\/p>\n

Uma biblioteca client-side tem duas vantagens: lat\u00eancia baixa (n\u00e3o tem hop extra de rede) e simplicidade operacional (n\u00e3o tem servidor para escalar). E duas fraquezas grandes quando o produto cresce:<\/p>\n

    \n
  • Toda mudan\u00e7a na biblioteca exige que cada servi\u00e7o-cliente fa\u00e7a deploy de nova vers\u00e3o. Corrigir um bug de acesso a dados vira uma coordena\u00e7\u00e3o com N times.<\/li>\n
  • N\u00e3o d\u00e1 para controlar centralmente coisas como rate limiting por tenant, circuit breaker, cache compartilhado ou roteamento inteligente entre regi\u00f5es. Cada processo do cliente tem sua pr\u00f3pria vis\u00e3o do mundo.<\/li>\n<\/ul>\n

    Por isso a OpenAI descreve a transi\u00e7\u00e3o para servi\u00e7o como necess\u00e1ria. O Habitat teve que crescer com a empresa: primeiro se tornando confi\u00e1vel o suficiente para tr\u00e1fego de produto cr\u00edtico, depois r\u00e1pido o suficiente para usu\u00e1rios globais, e por fim, operando com destreza em escala massiva. Cada uma dessas tr\u00eas fases resolve um problema diferente, e a ordem importa: n\u00e3o adianta ser r\u00e1pido se n\u00e3o \u00e9 confi\u00e1vel, e n\u00e3o adianta ser r\u00e1pido e confi\u00e1vel se n\u00e3o escala.<\/p>\n

    Por que Python num caminho de serving?<\/h3>\n

    Esse \u00e9 o detalhe mais estranho do an\u00fancio, e o que a pr\u00f3pria OpenAI reconhece como incomum. A ideia foi esticar um servi\u00e7o escrito em uma linguagem incomum para stack de serving, Python, em uma camada de storage confi\u00e1vel.<\/p>\n

    Storage layers de alta throughput em geral s\u00e3o escritas em Go, Rust, Java ou C++, por raz\u00f5es \u00f3bvias: GIL, custo de contexto, lat\u00eancia de garbage collector, e por a\u00ed vai. Python num servi\u00e7o que lida com dezenas de milh\u00f5es de requests por segundo \u00e9 uma escolha que exige justificativa, e a Parte 1 do post promete tratar disso. O que d\u00e1 para especular com seguran\u00e7a: se a biblioteca original j\u00e1 era Python (porque o resto do stack de aplica\u00e7\u00e3o da OpenAI \u00e9 Python), transformar em servi\u00e7o em Python evita reescrita e mant\u00e9m o mesmo modelo mental para os times de produto. O custo \u00e9 ter que investir pesado em async, pooling e provavelmente em partes cr\u00edticas escritas em extens\u00f5es nativas. Mas isso \u00e9 hip\u00f3tese, o post p\u00fablico n\u00e3o confirma esse racioc\u00ednio.<\/p>\n

    Onde entra o Azure Cosmos DB<\/h3>\n

    O Habitat n\u00e3o \u00e9 um banco. \u00c9 a camada acima do banco. O banco \u00e9 o Azure Cosmos DB, e a Microsoft confirmou publicamente essa parceria em outubro de 2025 no an\u00fancio do SDK Python 4.14.0 do Cosmos DB. Muitas das features desse SDK foram desenvolvidas em parceria pr\u00f3xima com a OpenAI, que depende bastante do Cosmos DB para armazenar dados de chat do ChatGPT em escala massiva. Foi uma release est\u00e1vel que combina performance, intelig\u00eancia e produtividade de desenvolvedor, com features provadas em cen\u00e1rios reais, incluindo alguns dos workloads de IA mais exigentes do mundo.<\/p>\n

    Muitas otimiza\u00e7\u00f5es 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\u00e2nticos em tempo real. Ou seja, o Habitat empurrou tanto o Cosmos DB que o pr\u00f3prio SDK evoluiu por causa dele. Esse \u00e9 o tipo de coisa que s\u00f3 acontece quando o cliente \u00e9 grande demais para ser tratado como cliente comum.<\/p>\n

    O que isso significa na pr\u00e1tica<\/h2>\n

    Se voc\u00ea est\u00e1 construindo algo do zero, o padr\u00e3o \u00e9 \u00fatil mesmo em escala muito menor. A ideia central \u00e9: coloque uma camada fina entre o seu c\u00f3digo de produto e o seu banco, e fa\u00e7a essa camada ser sua<\/strong>. No come\u00e7o \u00e9 uma biblioteca, depois pode virar servi\u00e7o.<\/p>\n

    Um esqueleto m\u00ednimo em Python, s\u00f3 para dar concretude:<\/p>\n

    class Habitat:\n def __init__(self, backend):\n self._backend = backend # cliente Cosmos, Postgres, o que for\n\n async def get(self, namespace: str, key: str):\n # ponto \u00fanico para adicionar cache, m\u00e9tricas, retry, rate limit\n return await self._backend.read(namespace, key)\n\n async def put(self, namespace: str, key: str, value: dict):\n # ponto \u00fanico para valida\u00e7\u00e3o, auditoria, replica\u00e7\u00e3o\n return await self._backend.write(namespace, key, value)\n<\/code><\/pre>\n
    O ponto n\u00e3o \u00e9 o c\u00f3digo. \u00c9 que get<\/code> e put<\/code> passam por um \u00fanico choke point. Quando amanh\u00e3 voc\u00ea precisa adicionar cache regional, circuit breaker por tenant, ou trocar de banco atr\u00e1s dos panos, voc\u00ea tem um<\/em> lugar para mexer. Se cada servi\u00e7o fala com o banco direto, voc\u00ea n\u00e3o tem esse lugar.<\/p>\n
    A transi\u00e7\u00e3o de biblioteca para servi\u00e7o se justifica quando:<\/p>\n
      \n
    • Voc\u00ea tem m\u00faltiplos times consumindo, e coordenar upgrade de biblioteca vira gargalo.<\/li>\n
    • Voc\u00ea quer aplicar pol\u00edticas globais (quota, prioridade, roteamento) que exigem vis\u00e3o agregada do tr\u00e1fego.<\/li>\n
    • Voc\u00ea precisa fazer connection pooling agressivo com o banco, e ter N clientes abrindo conex\u00f5es independentes vira problema.<\/li>\n<\/ul>\n
      Onde isso quebra ou n\u00e3o vale a pena<\/h2>\n
      Vamos ser espec\u00edficos sobre o que n\u00e3o<\/em> \u00e9 bom no modelo Habitat, tanto em geral quanto na vers\u00e3o da OpenAI:<\/p>\n
        \n
      • Lat\u00eancia.<\/strong> Colocar um servi\u00e7o entre a aplica\u00e7\u00e3o e o banco adiciona pelo menos um hop de rede. Em cargas onde a lat\u00eancia interna do banco \u00e9 1 a 2 ms, adicionar 1 ms de proxy \u00e9 50 a 100 por cento a mais. S\u00f3 vale se o que a camada faz (cache, roteamento, batching) compensa esse custo.<\/li>\n
      • Ponto \u00fanico de falha.<\/strong> Se o Habitat cai, tudo cai. A OpenAI descreve isso indiretamente ao dizer que se os requests s\u00e3o lentos, o produto parece lento, e se os requests falham, o produto para de funcionar por completo. \u00c9 um problema resolv\u00edvel (replica\u00e7\u00e3o, multi-regi\u00e3o) mas caro.<\/li>\n
      • Python em hot path.<\/strong> A menos que voc\u00ea tenha equipe para lidar com async, uvloop, extens\u00f5es em C ou Rust, e profiling cont\u00ednuo, n\u00e3o \u00e9 recomend\u00e1vel copiar essa parte. A OpenAI conseguiu porque tem gente dedicada s\u00f3 para isso. Numa startup pequena, Go ou Rust d\u00e1 menos dor de cabe\u00e7a.<\/li>\n
      • Custo.<\/strong> 500 petabytes em Cosmos DB globalmente distribu\u00eddo n\u00e3o \u00e9 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\u00eas anos sem esse tipo de abstra\u00e7\u00e3o.<\/li>\n<\/ul>\n
        O que n\u00e3o d\u00e1 para afirmar ainda<\/h2>\n
        Alguns pontos n\u00e3o est\u00e3o esclarecidos na publica\u00e7\u00e3o atual, porque o artigo \u00e9 a Parte 1:<\/p>\n
          \n
        • O mecanismo interno de como o Habitat faz sharding, replica\u00e7\u00e3o ou consist\u00eancia n\u00e3o est\u00e1 detalhado. A parte t\u00e9cnica pesada foi prometida para a Parte 2, que segundo o pr\u00f3prio post vai cobrir confiabilidade de multi-tenancy em escala, a estrat\u00e9gia em camadas para otimizar performance de leitura, e como escalaram a parceria com Azure Cosmos DB para lidar com demanda sem precedentes.<\/li>\n
        • A escolha de continuar<\/em> em Python no serving layer \u00e9 mencionada mas n\u00e3o justificada em profundidade no post p\u00fablico. A leitura sobre reuso de c\u00f3digo e produtividade \u00e9 hip\u00f3tese, n\u00e3o fato confirmado.<\/li>\n
        • N\u00e3o h\u00e1 benchmarks p\u00fablicos comparando o Habitat com alternativas (por exemplo, cliente Cosmos direto, ou proxies como Envoy com plugins). N\u00e3o d\u00e1 para afirmar que a abordagem \u00e9 \u00f3tima em termos de custo por request.<\/li>\n
        • Discrep\u00e2ncia nos n\u00fameros: 22M req\/s em refer\u00eancias p\u00fablicas versus 70M req\/s no corpo do artigo. N\u00e3o est\u00e1 claro se um \u00e9 hist\u00f3rico e outro atual, ou se houve revis\u00e3o. Ficam registrados os dois.<\/li>\n
        • O Habitat n\u00e3o \u00e9 open source. Tudo que se pode dizer vem do que a OpenAI e a Microsoft publicaram, mais conhecimento gen\u00e9rico sobre padr\u00f5es de storage.<\/li>\n<\/ul>\n
          Como testar isso voc\u00ea mesmo<\/h2>\n
          Voc\u00ea n\u00e3o vai rodar o Habitat, mas d\u00e1 para reproduzir o padr\u00e3o em pequena escala e sentir onde ele come\u00e7a a fazer sentido. Um exerc\u00edcio de uma tarde:<\/p>\n
            \n
          1. Escolha um projeto seu que fala direto com Postgres, Mongo ou similar.<\/li>\n
          2. Crie um m\u00f3dulo storage.py<\/code> com uma classe que exponha s\u00f3 get<\/code>, put<\/code>, query<\/code>, cada um recebendo namespace<\/code> e key<\/code>. Substitua todas as chamadas diretas ao banco por chamadas a essa classe.<\/li>\n
          3. Adicione logging estruturado dentro do m\u00f3dulo, contando requests por namespace, lat\u00eancia p50 e p99, e taxa de erro.<\/li>\n
          4. Rode em produ\u00e7\u00e3o (ou staging com tr\u00e1fego real) por uma semana. Olhe o que voc\u00ea aprende sobre o pr\u00f3prio produto. Provavelmente vai descobrir que 80 por cento do tr\u00e1fego \u00e9 em 3 ou 4 padr\u00f5es de acesso, e que d\u00e1 para cachear grande parte disso trivialmente.<\/li>\n
          5. S\u00f3 depois<\/em> disso, se fizer sentido, considere transformar o m\u00f3dulo em servi\u00e7o HTTP ou gRPC separado. Se n\u00e3o fizer sentido, voc\u00ea ganhou observabilidade e um choke point de gra\u00e7a.<\/li>\n<\/ol>\n
            Esse \u00e9 o valor pr\u00e1tico da hist\u00f3ria do Habitat, independente da escala da OpenAI: a camada de storage pr\u00f3pria n\u00e3o come\u00e7a como plataforma distribu\u00edda. Come\u00e7a como uma classe. O resto \u00e9 consequ\u00eancia de sobreviver ao crescimento.<\/p>\n","protected":false},"excerpt":{"rendered":"
            Como a OpenAI transformou o Habitat, sua camada de storage, de biblioteca Python para servi\u00e7o distribu\u00eddo sobre Azure Cosmos DB. O que d\u00e1 para aprender disso.<\/p>\n","protected":false},"author":2,"featured_media":705,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-706","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/posts\/706","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/comments?post=706"}],"version-history":[{"count":0,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/posts\/706\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/media\/705"}],"wp:attachment":[{"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/media?parent=706"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/categories?post=706"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/tags?post=706"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}