OpenAI: um primário Postgres para 800 milhões de usuários do ChatGPT

01 · CONTEXTO

Um escritor para centenas de milhões de usuários

A OpenAI descreve como sustenta milhões de consultas por segundo para 800 milhões de usuários com um único primário PostgreSQL que atende todas as escritas e quase 50 réplicas de leitura espalhadas por várias regiões.

A carga do banco cresceu mais de dez vezes em um ano e segue subindo. O desenho se sustenta porque a carga é majoritariamente de leitura; a empresa diz que isso, somado às otimizações, ainda deixa folga para crescer.

Uma arquitetura de primário único significa que uma instância trata todas as escritas enquanto várias réplicas tratam as leituras. Isso cria um gargalo inerente, porque as escritas não podem ser distribuídas. O caso mostra até onde dá para empurrar esse desenho antes de partir para fragmentação.

02 · A ESCOLHA

Por que não fragmentar o banco

O PostgreSQL da OpenAI permaneceu sem fragmentação. O motivo central é que fragmentar as cargas existentes seria complexo e demorado, exigindo mudanças em centenas de endpoints e podendo levar meses ou até anos. Como a carga é majoritariamente de leitura e há otimizações extensas, a arquitetura atual ainda oferece folga; a empresa não descarta fragmentar no futuro, mas não é prioridade de curto prazo.

03 · ARQUITETURA

Um escritor, muitas réplicas e cache

A OpenAI combinou aumentar o tamanho da instância (escala vertical) com adicionar mais réplicas de leitura (escala horizontal). O diagrama mostra o desenho resultante.

1. Todas as escritas do PostgreSQL chegam ao único primário.

2. As leituras vão para as réplicas sempre que possível; só ficam no primário as leituras que fazem parte de transações de escrita.

3. Uma camada de cache atende a maior parte do tráfego de leitura para aliviar o PostgreSQL.

4. As escritas pesadas que podem ser particionadas vão para um sistema fragmentado, e as cargas novas nascem nele.

5. O primário transmite o log de escrita (WAL) a cada réplica de leitura.

04 · ALIVIAR O PRIMÁRIO

Escritas, consultas e conexões sob controle

Na frente de escrita, a OpenAI corrigiu bugs de aplicação que geravam escritas redundantes e introduziu escritas preguiçosas, onde cabível, para suavizar picos. Na frente de consultas, uma query que juntava 12 tabelas esteve por trás de incidentes graves quando seu volume subia; a lição foi evitar joins complexos e, quando necessários, quebrar a consulta e levar a lógica de junção para a aplicação.

Muitas consultas problemáticas vêm de ORMs, então é importante revisar o SQL que eles geram. Também é preciso configurar timeouts, como idle_in_transaction_session_timeout, para que consultas ociosas não bloqueiem o autovacuum. Esses são exemplos dos anti-padrões de desempenho em bancos transacionais.

Cada instância tem um limite máximo de conexões (5.000 no Azure PostgreSQL), e a OpenAI já teve incidentes em que tempestades de conexões esgotaram todas as disponíveis. A resposta foi o PgBouncer, um proxy que agrupa e reutiliza conexões; em benchmarks, o tempo médio de conexão caiu de 50 ms para 5 ms.

1. Cada instância de banco tem um limite máximo de conexões, e tempestades de conexões já esgotaram esse limite em incidentes passados.

2. O PgBouncer fica como proxy entre as aplicações e o banco e reutiliza conexões, reduzindo as conexões ativas dos clientes.

3. Cada réplica tem seu próprio deployment Kubernetes com vários pods PgBouncer, atrás de um mesmo Service que balanceia o tráfego entre os pods.

4. Proxy, clientes e réplicas ficam na mesma região para reduzir a sobrecarga de rede.

05 · FALHAS EM CASCATA

Cache, isolamento e limites de taxa

Os incidentes de sobrecarga costumam seguir um padrão: um problema a montante provoca um pico de carga no banco, como misses generalizados do cache, um surto de joins caros saturando a CPU ou uma tempestade de escritas de uma funcionalidade nova. Com o uso de recursos subindo, a latência aumenta, as requisições expiram e as retentativas amplificam a carga em um ciclo vicioso que pode degradar o serviço inteiro.

1. A taxa de acerto do cache cai de repente por uma falha na camada de cache.

2. O surto de misses empurra um grande volume de requisições direto para o PostgreSQL.

3. Com a trava de chave, só uma requisição busca o dado no banco e repovoa o cache; as outras esperam a atualização.

4. Requisições de baixa e alta prioridade vão a instâncias separadas, então um pico de baixa prioridade não degrada o tráfego crítico.

O isolamento de cargas vale também entre produtos e serviços, para que a atividade de um não afete a confiabilidade de outro. Além disso, a OpenAI aplica limitação de taxa em várias camadas (aplicação, pooler de conexões, proxy e consulta) e evita intervalos de retentativa curtos demais, que podem causar tempestades de retentativas.

A camada de ORM também foi estendida para limitar taxa e, quando necessário, bloquear por completo certos padrões de consulta. Essa forma de load shedding permite recuperação rápida de surtos de consultas caras.

06 · DISPONIBILIDADE E LIMITES

O ponto único de falha e o teto do desenho

Com um único escritor, se ele cair o serviço inteiro é afetado. Por isso as leituras críticas foram tiradas do primário: se ele cair, elas continuam sendo atendidas pelas réplicas. As escritas ainda falhariam, mas o impacto é menor.

1. Cenário de falha: o primário cai e as escritas passam a falhar.

2. As leituras críticas continuam sendo atendidas pelas réplicas.

3. O standby quente, sincronizado continuamente, pode ser promovido para reduzir o tempo fora do ar.

4. Com várias réplicas por região e folga de capacidade, a falha de uma réplica não causa queda regional.

O desenho tem um teto. Como o primário transmite o WAL a cada réplica, mais réplicas aumentam a pressão em rede e CPU e deixam o atraso de replicação maior e mais instável. A OpenAI diz que não pode adicionar réplicas indefinidamente sem sobrecarregar o primário.

A saída em estudo é a replicação em cascata, em que réplicas intermediárias repassam o WAL às seguintes, o que permitiria passar de cem réplicas. O custo é complexidade operacional, sobretudo no failover, e a funcionalidade ainda estava em teste.

Há limites também no próprio PostgreSQL. O MVCC copia a linha inteira a cada atualização, o que amplifica a escrita, e as leituras precisam percorrer versões mortas, o que amplifica a leitura. Até uma mudança pequena de esquema pode reescrever a tabela inteira; por isso só mudanças leves são permitidas, com timeout estrito de cinco segundos, e preenchimentos retroativos com limite de taxa podem levar mais de uma semana.

07 · RESULTADOS

O que o desenho entregou e onde ele dói

A OpenAI relata milhões de consultas por segundo em cargas de leitura intensa, quase 50 réplicas adicionadas com atraso de replicação próximo de zero, latência p99 de dois dígitos baixos em milissegundos no cliente e disponibilidade de cinco noves.

Em doze meses houve apenas um incidente SEV-0 do PostgreSQL. Ele ocorreu no lançamento do ChatGPT ImageGen, quando o tráfego de escrita subiu mais de dez vezes com mais de cem milhões de novos usuários em uma semana.

A empresa segue migrando as cargas de escrita restantes, mais difíceis de fragmentar, e diz que continuará explorando outras abordagens, incluindo PostgreSQL fragmentado ou sistemas distribuídos alternativos.