PostgreSQL para 800 milhões de usuários: como a OpenAI escala seu banco de dados sem sharding

Enquanto bancos de dados vetoriais ainda têm muitos casos de uso válidos, organizações como a OpenAI estão confiando no PostgreSQL para fazer o trabalho pesado. E não estamos falando de pequenos volumes: estamos falando de 800 milhões de usuários.

Em uma divulgação técnica recente, a OpenAI revelou como está utilizando o banco de dados open-source PostgreSQL para suportar o ChatGPT e sua plataforma de API. A revelação desafia a sabedoria convencional sobre escalabilidade de bancos de dados e oferece lições valiosas para arquitetos de dados enterprise.

A abordagem "single-primary" que desafia o senso comum

A OpenAI executa o ChatGPT e sua plataforma de API para 800 milhões de usuários em uma única instância primary do PostgreSQL — não um banco de dados distribuído, não um cluster com sharding. Uma única instância Azure PostgreSQL Flexible Server gerencia todas as escritas. Cerca de 50 réplicas de leitura distribuídas em múltiplas regiões lidam com as consultas de leitura.

O sistema processa milhões de queries por segundo mantendo latência p99 em dois dígitos baixos (em milissegundos) e disponibilidade de cinco noves (99.999%).

"Por anos, o PostgreSQL tem sido um dos sistemas de dados mais críticos nos bastidores, alimentando produtos core como o ChatGPT e a API da OpenAI", escreveu Bohan Zhang, engenheiro da OpenAI, em uma divulgação técnica. "No último ano, nossa carga do PostgreSQL cresceu mais de 10x, e continua subindo rapidamente."

Por que essa configuração importa?

Esta configuração desafia a sabedoria convencional de escalabilidade e oferece aos arquitetos enterprise insights sobre o que realmente funciona em escala massiva. A lição aqui não é copiar a stack da OpenAI cegamente. É que decisões arquiteturais devem ser orientadas por padrões de workload e restrições operacionais — não por pânico de escala ou escolhas de infraestrutura da moda.

Os desafios do PostgreSQL em alta escala

O PostgreSQL lida com dados operacionais para o ChatGPT e a plataforma de API da OpenAI. A carga de trabalho é fortemente orientada a leitura, o que torna o PostgreSQL uma boa escolha. No entanto, o controle de concorrência multiversão (MVCC) do PostgreSQL cria desafios sob cargas pesadas de escrita.

Como funciona o MVCC

Ao atualizar dados, o PostgreSQL copia linhas inteiras para criar novas versões, causando amplificação de escrita e forçando queries a escanear múltiplas versões para encontrar dados atuais.

Em vez de lutar contra essa limitação, a OpenAI construiu sua estratégia em torno dela. Na escala da OpenAI, esses tradeoffs não são teóricos — eles determinam quais workloads permanecem no PostgreSQL e quais precisam migrar para outros sistemas.

7 otimizações críticas implementadas pela OpenAI

Na grande escala, a sabedoria convencional de banco de dados aponta para um de dois caminhos: fazer sharding do PostgreSQL em múltiplas instâncias primary para que escritas possam ser distribuídas, ou migrar para um banco SQL distribuído como CockroachDB ou YugabyteDB, projetados para lidar com escala massiva desde o início.

A maioria das organizações teria tomado um desses caminhos anos atrás, bem antes de atingir 800 milhões de usuários. Mas a OpenAI escolheu um caminho diferente.

1. Estratégia híbrida: sem novas tabelas no PostgreSQL

Em vez de fazer sharding do PostgreSQL, a OpenAI estabeleceu uma estratégia híbrida:

• Sem novas tabelas no PostgreSQL: novos workloads usam sistemas com sharding como Azure Cosmos DB por padrão

• Migração seletiva: workloads pesados em escrita que podem ser particionados horizontalmente são migrados

• Otimização agressiva: tudo o mais permanece no PostgreSQL com otimizações intensivas

Esta abordagem oferece às empresas uma alternativa prática à rearquitetura completa. Em vez de gastar anos reescrevendo centenas de endpoints, equipes podem identificar gargalos específicos e mover apenas esses workloads para sistemas especializados.

2. Connection pooling otimizado

A OpenAI reduziu o tempo de conexão de 50 milissegundos para 5 milissegundos através de connection pooling otimizado. Esta mudança teve impacto direto na experiência do usuário e na capacidade de lidar com picos de tráfego.

3. Cache locking para prevenir "thundering herd"

Cache locking foi implementado para prevenir problemas de "thundering herd", onde cache misses disparam sobrecarga no banco de dados. Esta técnica garante que apenas uma requisição busque dados no banco quando o cache expira, enquanto outras requisições aguardam.

4. Isolamento de workload por prioridade

O tráfego de baixa e alta prioridade é roteado para instâncias separadas, garantindo que um novo recurso mal otimizado não possa degradar serviços core. Esta separação é fundamental para manter a disponibilidade do sistema.

5. Rate limiting em múltiplas camadas

Rate limiting foi implementado em três níveis:

6. Disciplina operacional estrita

A OpenAI implementou regras rígidas de operação:

• Schema changes leves apenas: qualquer mudança que dispare full table rewrite é proibida

• Timeout de 5 segundos: mudanças de schema têm limite de tempo curto

• Terminação automática: queries de longa duração são automaticamente terminadas para prevenir bloqueio de operações de manutenção

• Rate limiting agressivo: ao fazer backfill de dados, os rate limits são tão agressivos que operações podem levar mais de uma semana

7. Monitoramento e revisão de SQL gerado por ORM

Frameworks ORM (Object-Relational Mapping) como Django, SQLAlchemy e Hibernate geram queries SQL automaticamente a partir do código da aplicação, o que é conveniente para desenvolvedores. No entanto, a OpenAI descobriu uma query gerada por ORM que fazia join de 12 tabelas e causou múltiplos incidentes de alta severidade quando o tráfego aumentou.

A conveniência de deixar frameworks gerarem SQL cria riscos ocultos de escalabilidade que só surgem sob carga de produção. Revisar essas queries deve ser uma prática padrão.

Lições para arquitetos de dados enterprise

A experiência da OpenAI escalando PostgreSQL revela várias práticas que empresas podem adotar independentemente de sua escala.

Workloads read-heavy com burst writes podem escalar mais do que se imagina

Workloads read-heavy com burst writes podem rodar em PostgreSQL single-primary por mais tempo do que comumente se assume. A decisão de fazer sharding deve depender de padrões de workload em vez de contagem de usuários.

Esta abordagem é particularmente relevante para aplicações de IA, que frequentemente têm workloads fortemente orientados a leitura com picos de tráfego imprevisíveis. Estas características se alinham com o padrão onde PostgreSQL single-primary escala efetivamente.

Otimize antes de re-arquitetar

Em vez de gastar anos em rearquitetura completa, identifique gargalos reais, otimize infraestrutura comprovada onde possível e migre seletivamente quando necessário. Rearquitetura completa nem sempre é a resposta para desafios de escalabilidade.

Construa defesas operacionais em múltiplas camadas

A abordagem da OpenAI combina cache locking para prevenir problemas de "thundering herd", connection pooling e rate limiting em níveis de aplicação, proxy e query.

FAQ: PostgreSQL em alta escala

Quando devo considerar sharding do PostgreSQL?

Considere sharding quando seu workload for write-heavy e não puder ser otimizado através de outras técnicas. Se seu workload é read-heavy, réplicas de leitura e otimizações podem ser suficientes, mesmo em grande escala.

PostgreSQL é adequado para aplicações de IA?

Sim. Aplicações de IA frequentemente têm workloads read-heavy com picos imprevisíveis, que se alinham bem com as forças do PostgreSQL single-primary com múltiplas réplicas de leitura.

Qual é a latência aceitável para queries em produção?

A OpenAI mantém latência p99 em dois dígitos baixos de milissegundos. Isso significa que 99% das queries são respondidas em menos de 100ms, um benchmark razoável para a maioria das aplicações enterprise.

Como prevenir que mudanças de schema causem downtime?

Implemente timeouts curtos (5 segundos), proíba mudanças que disparem full table rewrite e teste todas as mudanças em ambiente de staging antes de produção.

O futuro do PostgreSQL em escala

A divulgação da OpenAI demonstra que PostgreSQL, quando otimizado corretamente, pode escalar muito além do que a sabedoria convencional sugere. A chave está em entender os padrões de workload, implementar otimizações direcionadas e fazer decisões arquiteturais baseadas em dados reais, não em modismos tecnológicos.

Para a comunidade Data Hackers, isso significa que antes de embarcar em uma migração custosa para bancos de dados distribuídos ou implementar sharding complexo, vale a pena explorar otimizações no PostgreSQL existente. A experiência da OpenAI prova que, com as técnicas certas, um banco de dados relacional tradicional pode suportar cargas de trabalho que muitos considerariam impossíveis.

A lição é direta: identifique gargalos reais, otimize infraestrutura comprovada onde possível e migre seletivamente quando necessário. Nem sempre a rearquitetura completa é a resposta para desafios de escalabilidade — às vezes, a resposta está em dominar completamente as ferramentas que você já tem.