A OpenAI publicou recentemente um case técnico que surpreendeu boa parte da comunidade de engenharia de dados. O ChatGPT, com 800 milhões de usuários ativos semanais, roda sobre um único servidor primário PostgreSQL. Sem sharding. Sem banco distribuído exótico. Um Postgres no Azure com quase 50 réplicas de leitura espalhadas pelo mundo.

O mais surpreendente não é a escala em si, mas a abordagem: em vez de redesenhar tudo para um sistema distribuído, a equipe apostou em otimizações incrementais sobre a mesma base PostgreSQL que já tinham. A carga do banco cresceu mais de 10x em 12 meses e, ainda assim, o sistema mantém latência p99 na casa dos milissegundos de dois dígitos e disponibilidade de cinco noves (99,999%).

Este post disseca as técnicas que a OpenAI usou para chegar a esse nível de escala.

A arquitetura: um primário, ~50 réplicas, zero sharding

O design é direto: uma instância primária PostgreSQL no Azure Database for PostgreSQL cuida de todas as escritas. As leituras são distribuídas entre quase 50 réplicas geográficas, cada uma recebendo o WAL (Write-Ahead Log) diretamente do primário.

O ChatGPT tem um perfil de carga que favorece esse modelo. Cada prompt do usuário gera uma escrita (a mensagem salva), mas dispara múltiplas leituras para contexto, histórico de conversas e metadados. Essa proporção leitura/escrita permite escalar as leituras horizontalmente via réplicas, sem precisar particionar os dados.

A replicação funciona com lag próximo de zero na maioria das condições. Réplicas múltiplas por região garantem que a falha de uma única réplica não cause indisponibilidade regional — há headroom de capacidade suficiente para absorver o tráfego redistribuído.

Para o futuro, a OpenAI está testando replicação em cascata junto com o time do Azure PostgreSQL. Em vez do primário transmitir WAL para todas as ~50 réplicas diretamente (o que já pressiona banda e CPU), réplicas intermediárias retransmitiriam para réplicas downstream. Isso abriria caminho para mais de 100 réplicas, com o trade-off de complexidade adicional no gerenciamento de failover.

Connection pooling com PgBouncer: de 50ms para 5ms

Antes do PgBouncer, cada conexão ao PostgreSQL levava em média 50ms para ser estabelecida. Depois de deployar PgBouncer em modo statement/transaction pooling, esse tempo caiu para 5ms — uma melhoria de 10x apenas com gerenciamento de conexões.

A topologia de deploy é pensada para minimizar latência de rede. Múltiplos pods PgBouncer rodam por deployment Kubernetes, por réplica de leitura. Um Kubernetes Service distribui o tráfego entre os pods. Proxy, aplicação e réplica ficam co-localizados na mesma região para eliminar latência cross-region.

Essa camada resolve um problema que aparece em qualquer aplicação com muitas instâncias de aplicação conectando ao mesmo banco: o overhead de criar e destruir conexões TCP+SSL com o PostgreSQL. Em vez de cada pod de aplicação manter sua própria conexão direta, o PgBouncer reutiliza um pool menor de conexões reais, multiplexando as requisições.

Cache locking e o problema do thundering herd

Imagine que uma chave popular no cache expira. No mesmo milissegundo, milhares de requisições percebem que o dado não está no cache e todas batem no PostgreSQL ao mesmo tempo para buscar o mesmo registro. Esse é o thundering herd — um estouro de cache misses simultâneos que pode derrubar o banco.

A solução da OpenAI é um mecanismo de cache locking com leasing. Quando múltiplas requisições falham no cache para a mesma chave, apenas uma adquire o lock e vai ao PostgreSQL buscar o dado. As demais esperam o cache ser repopulado. O resultado: uma leitura no banco em vez de milhares.

Isso se tornou ainda mais relevante conforme a carga cresceu. Cenários de falha que a equipe mapeou incluem queda generalizada da camada de cache (todas as chaves expiram de uma vez), queries com JOINs pesados saturando CPU quando chegam em volume, e write storms durante lançamentos de features novas.

Por que não shardar (e onde entra o CosmosDB)

Shardar o PostgreSQL exigiria modificar centenas de endpoints na aplicação. Cada query que acessa dados particionados precisaria de routing logic. A estimativa da equipe era de meses — possivelmente anos — para completar a migração. O custo de oportunidade era alto demais.

A decisão pragmática foi outra: não shardar o Postgres, mas migrar workloads de escrita pesada para sistemas que já nasceram shardados. O Azure CosmosDB absorveu cargas como logs de auditoria e estado temporário — dados que podem ser particionados horizontalmente sem coordenação complexa.

A política resultante é clara:

  • Nenhuma tabela nova no PostgreSQL
  • Workloads novos vão direto para sistemas shardados
  • Workloads existentes que podem ser particionados são migrados gradualmente
  • O que fica no Postgres recebe otimização agressiva

Essa abordagem congela a complexidade do monolito PostgreSQL. Novas features são forçadas para datastores separados, enquanto o Postgres existente opera com escopo fechado e otimizado.

O MVCC (Multi-Version Concurrency Control) do PostgreSQL tem custo em cenários de escrita intensiva. Cada UPDATE copia a row inteira (write amplification), leituras precisam escanear dead tuples (read amplification), e o VACUUM precisa rodar constantemente para evitar bloat de tabelas e índices. Com menos escritas no Postgres, esses problemas ficam sob controle.

Disciplina operacional: schema changes, rate limiting e isolamento

Três pilares operacionais sustentam a estabilidade do sistema.

O primeiro é o controle rígido de schema changes. Apenas alterações leves são permitidas (adicionar ou remover colunas simples). Toda alteração de schema tem um timeout de 5 segundos — se não completar nesse tempo, é abortada. Índices são criados e removidos com CONCURRENTLY para não bloquear leituras. Full table rewrites são proibidos. Backfills operam com rate limit estrito e podem levar mais de uma semana para completar.

O segundo pilar é rate limiting em múltiplas camadas. A OpenAI aplica limites na aplicação, no connection pooler, no proxy e no nível de query. O ORM foi customizado para suportar rate limiting nativo e pode bloquear patterns de query específicos quando necessário. Uma query particularmente problemática que fazia JOIN de 12 tabelas causou múltiplos incidentes de alta severidade antes de ser decomposta em queries mais simples com a lógica de JOIN movida para a camada de aplicação.

O terceiro pilar é isolamento de workloads. Requisições são classificadas em tiers de baixa e alta prioridade, roteadas para instâncias de banco separadas. Jobs de background e tarefas batch não competem com o tráfego de usuários reais. Uma spike em jobs de baixa prioridade não degrada a experiência do ChatGPT.

O incidente do ImageGen: 100 milhões de usuários em uma semana

O único incidente SEV-0 de PostgreSQL nos últimos 12 meses aconteceu durante o lançamento do ChatGPT ImageGen. O tráfego de escrita saltou mais de 10x quando mais de 100 milhões de novos usuários se cadastraram em uma semana.

Foi o tipo de evento que testa todos os mecanismos de proteção de uma vez. Rate limiting, cache locking, isolamento de workloads — tudo precisou absorver um volume de escrita que ninguém havia planejado para aquele timeline.

O fato de ter sido o único SEV-0 em um ano diz algo sobre a resiliência da arquitetura. O primário tem um hot standby em modo High Availability, continuamente sincronizado e pronto para promoção imediata. As leituras mais críticas já rodavam nas réplicas, protegendo o primário de sobrecarga mesmo em cenários normais.

Conclusão

A lição central desse case não é "use PostgreSQL para tudo". É que sistemas evoluem por restrição, não por redesign completo. A OpenAI não projetou a arquitetura perfeita desde o início. Ela herdou um Postgres, identificou os gargalos reais e aplicou otimizações cirúrgicas: connection pooling, cache locking, migração seletiva de escritas, rate limiting em camadas, isolamento de workloads.

O PostgreSQL 18, com async I/O nativo, promete aliviar ainda mais a pressão de I/O que a OpenAI enfrenta. A replicação em cascata, quando estiver pronta, vai desbloquear o próximo patamar de escala de leitura.

Para quem opera PostgreSQL em produção, vale mapear quais dessas técnicas se aplicam ao seu contexto. PgBouncer e cache locking são investimentos de baixo risco com retorno imediato. A migração seletiva de escritas exige mais planejamento, mas evita a complexidade de sharding. E o rate limiting em múltiplas camadas é o tipo de proteção que você agradece ter montado antes de precisar.

Referências pesquisadas nesta publicação