Posted on: February 18, 2026 05:02 PM
Posted by: Renato
Categories: postgres postgresql inteligencia-artificial ia
Views: 112
PostgreSQL na Escala de 800 Milhões: Como a OpenAI Sustenta o ChatGPT
O senso comum no mundo da tecnologia costuma ditar que, ao atingir uma escala "planetária", as empresas devem abandonar soluções Open Source em favor de bancos de dados proprietários caríssimos ou arquiteturas de sistemas distribuídos ultra-complexas.
A OpenAI acaba de provar que esse pensamento está obsoleto.
Em um relatório técnico recente, Bohan Zhang, membro da equipe técnica da OpenAI, revelou como o PostgreSQL — um projeto de código aberto nascido na UC Berkeley — é o coração que sustenta o ChatGPT e sua API global.
Os Números da Operação
A escala descrita é, no mínimo, impressionante:
-
Usuários: 800 milhões de pessoas.
-
Volume: Milhões de consultas por segundo (QPS).
-
Crescimento: 10x em apenas um ano.
-
Performance: Latência P99 na casa dos dois dígitos de milissegundos.
-
Disponibilidade: "Cinco noves" (99,999%).
A Arquitetura: Simplicidade Encontra a Engenharia de Elite
O que mais surpreende no case da OpenAI é a escolha por manter uma única instância primária de gravação no Azure PostgreSQL Flexible Server, complementada por cerca de 50 réplicas de leitura distribuídas globalmente.
Para evitar que essa estrutura colapsasse sob o peso de milhões de usuários, a equipe focou em cinco pilares de otimização:
1. Descarregamento Agressivo de Leitura
Para proteger o servidor primário (o único que escreve dados), a OpenAI garante que quase todo o tráfego de consulta seja direcionado para as réplicas. Mesmo leituras críticas foram movidas, garantindo que, se o servidor de escrita falhar, o serviço continue disponível para consulta (modo leitura).
2. O Dilema do MVCC e a Escrita
O PostgreSQL utiliza o Multi-Version Concurrency Control (MVCC). Embora excelente para consistência, ele gera "inchaço" (bloat) em cargas massivas de escrita, pois cada atualização cria uma nova versão da linha.
A Solução: A OpenAI migrou cargas de escrita intensiva e facilmente particionáveis para sistemas fragmentados (como Azure Cosmos DB), mantendo no Postgres o que exige alta integridade e relacionamentos complexos.
3. Pool de Conexões com PgBouncer
Gerenciar milhares de conexões diretas mataria a performance. Ao implementar o PgBouncer, a OpenAI reduziu o tempo de estabelecimento de conexão de 50ms para 5ms, além de permitir a reutilização eficiente de sessões.
4. Blindagem contra "Tempestades de Cache"
Quando um cache falha, milhares de requisições batem no banco simultaneamente. A OpenAI implementou um mecanismo de lock de cache: apenas a primeira requisição vai ao PostgreSQL buscar o dado; todas as outras aguardam o cache ser repopulado, evitando o efeito manada.
Por que empresas ainda pagam por soluções proprietárias?
O case da OpenAI levanta uma questão provocativa para CTOs e gestores de TI: Se a infraestrutura de IA mais avançada do mundo confia no Open Source, por que sua empresa ainda gasta fortunas com licenciamento de bancos proprietários?
Ao optar pelo PostgreSQL (Open Source), as empresas ganham:
-
Custo Zero de Licença: O orçamento é investido em engenharia e inovação, não em permissão de uso.
-
Sem Vendor Lock-in: Você pode rodar o mesmo banco no Azure, AWS, On-premises ou Google Cloud.
-
Ecossistema Vibrante: Milhares de desenvolvedores corrigindo bugs e criando extensões diariamente.
-
Escalabilidade Provada: O "teto" do PostgreSQL é muito mais alto do que a maioria das empresas jamais precisará atingir.
Conclusão
A lição da OpenAI é clara: Escalabilidade não é um produto que se compra com uma licença cara; é um resultado de boa arquitetura e engenharia sólida. O PostgreSQL não é apenas um "banco de dados gratuito", é uma ferramenta de alta performance capaz de sustentar o futuro da inteligência artificial.
Gostou dessa análise técnica?
o MVCC (o motor de concorrência) e o PgBouncer (o porteiro das conexões).
1. O Motor Interno: MVCC e o "Lado Sombrio" da Escrita
O PostgreSQL utiliza o Multi-Version Concurrency Control (MVCC) para permitir que leituras e escritas aconteçam simultaneamente sem que um bloqueie o outro.
Como funciona na prática:
-
Imutabilidade: Quando você faz um
UPDATEem uma linha, o Postgres não apaga o dado antigo. Ele marca a linha antiga como "expirada" e cria uma nova versão da linha com os dados atualizados. -
Visibilidade: Cada transação vê apenas as versões dos dados que eram válidas no momento em que ela começou. Isso garante isolamento total.
O Desafio da OpenAI:
Em uma escala de 800 milhões de usuários, o excesso de UPDATES gera muitas "linhas mortas" (dead tuples). Isso causa o chamado Bloat (inchaço), que aumenta o consumo de disco e torna os índices mais lentos. Por isso, a OpenAI migrou tabelas de escrita frenética para sistemas fragmentados, deixando no Postgres o que exige a robustez relacional.
2. O Porteiro: PgBouncer e o Pool de Conexões
Cada conexão direta ao PostgreSQL consome memória RAM e CPU no servidor. Se 10.000 usuários tentassem abrir conexões simultâneas, o banco travaria apenas tentando gerenciar o "aperto de mão" (handshake) de cada uma.
A Mágica do PgBouncer:
O PgBouncer atua como um proxy intermediário. Milhares de servidores de aplicação se conectam ao PgBouncer, mas ele mantém apenas um número pequeno e fixo de conexões reais com o banco de dados.
Por que a OpenAI viu um ganho de 50ms para 5ms?
-
Sem Handshake: A aplicação não precisa mais negociar uma nova conexão com o Postgres toda vez; ela pega uma conexão "quente" e já aberta no pool do PgBouncer.
-
Transaction Pooling: O PgBouncer libera a conexão para outro processo assim que uma transação termina, em vez de esperar o usuário fechar a sessão.
3. A Estratégia de "Five Nines" (99,999%)
Para manter essa disponibilidade, a OpenAI usa uma arquitetura de Alta Disponibilidade (HA) com réplicas de leitura em cascata.
| Componente | Função na OpenAI |
| Instância Primária | Única fonte de verdade para escritas (Azure PostgreSQL). |
| Réplicas (50+) | Distribuídas globalmente para atender leituras com latência mínima. |
| Failover Automático | Se o primário cai, uma réplica assume em segundos. |
| Replicação em Cascata | Réplicas que enviam dados para outras réplicas, tirando o peso do servidor principal. |
O próximo passo para sua empresa
O case da OpenAI prova que o segredo não é o tamanho do cheque assinado para um fornecedor de software, mas a maturidade da engenharia.
Donate to Site
Renato
Developer