Embora os bancos de dados vetoriais ainda tenham muitos casos de uso válidos, organizações como a OpenAI estão contando com o PostgreSQL para realizar suas tarefas.
Em um postagem no blog na quinta-feiraa OpenAI divulgou como está usando o banco de dados PostgreSQL de código aberto.
OpenAI executa ChatGPT e sua plataforma API para 800 milhões de usuários em uma instância PostgreSQL primária única – não um banco de dados distribuído, não um cluster fragmentado. Um servidor flexível do Azure PostgreSQL lida com todas as gravações. Quase 50 réplicas de leitura espalhadas por várias regiões lidam com leituras. O sistema processa milhões de consultas por segundo, mantendo baixa latência p99 de dois dígitos em milissegundos e disponibilidade de cinco noves.
A configuração desafia a sabedoria convencional de dimensionamento e oferece aos arquitetos corporativos uma visão sobre o que realmente funciona em grande escala.
TA lição aqui não é copiar a pilha do OpenAI. É que as decisões arquitetônicas devem ser orientadas por padrões de carga de trabalho e restrições operacionais — e não por pânico de escala ou por escolhas modernas de infraestrutura. A configuração do PostgreSQL da OpenAI mostra até que ponto os sistemas comprovados podem ser ampliados quando as equipes otimizam deliberadamente em vez de reprojetar prematuramente.
“Durante anos, o PostgreSQL tem sido um dos sistemas de dados mais críticos e ocultos que alimentam produtos essenciais como ChatGPT e API da OpenAI”, escreveu o engenheiro da OpenAI Bohan Zhang em uma divulgação técnica. “Durante o ano passado, nossa carga de PostgreSQL cresceu mais de 10 vezes e continua aumentando rapidamente.”
A empresa alcançou essa escala por meio de otimizações direcionadas, incluindo pool de conexões que reduziu o tempo de conexão de 50 milissegundos para 5 milissegundos e bloqueio de cache para evitar problemas de “rebanho trovejante”, onde falhas de cache desencadeiam sobrecarga de banco de dados.
Por que o PostgreSQL é importante para as empresas
PostgreSQL lida com dados operacionais para ChatGPT e plataforma API da OpenAI. A carga de trabalho é fortemente orientada para leitura, o que torna o PostgreSQL uma boa opção. No entanto, o controle de simultaneidade multiversão (MVCC) do PostgreSQL cria desafios sob cargas pesadas de gravação.
Ao atualizar os dados, o PostgreSQL copia linhas inteiras para criar novas versões, causando amplificação de gravação e forçando as consultas a examinar múltiplas versões para encontrar os dados atuais.
Em vez de lutar contra esta limitação, a OpenAI construiu a sua estratégia em torno dela. Na escala da OpenAI, essas compensações não são teóricas – elas determinam quais cargas de trabalho permanecem no PostgreSQL e quais devem ser transferidas para outro lugar.
Como a OpenAI está otimizando o PostgreSQL
Em grande escala, o conhecimento convencional sobre bancos de dados aponta para um de dois caminhos: fragmentar o PostgreSQL em várias instâncias primárias para que as gravações possam ser distribuídas ou migrar para um banco de dados SQL distribuído, como CockroachDB ou YugabyteDB, projetado para lidar com escala massiva desde o início. A maioria das organizações teria seguido um destes caminhos há anos, muito antes de atingir 800 milhões de utilizadores.
A fragmentação ou migração para um banco de dados SQL distribuído elimina o gargalo do gravador único. Um banco de dados SQL distribuído lida com essa coordenação automaticamente, mas ambas as abordagens introduzem uma complexidade significativa: o código do aplicativo deve encaminhar as consultas para o fragmento correto, as transações distribuídas tornam-se mais difíceis de gerenciar e a sobrecarga operacional aumenta substancialmente.
Em vez de fragmentar o PostgreSQL, a OpenAI estabeleceu uma estratégia híbrida: não há novas tabelas no PostgreSQL. As novas cargas de trabalho são padronizadas para sistemas fragmentados como o Azure Cosmos DB. Cargas de trabalho existentes com muita gravação que podem ser particionadas horizontalmente são migradas. Todo o resto permanece no PostgreSQL com otimização agressiva.
Esta abordagem oferece às empresas uma alternativa prática à rearquitetura grossista. Em vez de passar anos reescrevendo centenas de endpoints, as equipes podem identificar gargalos específicos e mover apenas essas cargas de trabalho para sistemas desenvolvidos especificamente.
Por que isso é importante
A experiência da OpenAI no dimensionamento do PostgreSQL revela diversas práticas que as empresas podem adotar, independentemente de sua escala.
Construa defesas operacionais em múltiplas camadas. A abordagem da OpenAI combina bloqueio de cache para evitar problemas de “rebanho trovejante”, pool de conexões (que reduziu o tempo de conexão de 50 ms para 5 ms) e limitação de taxa nos níveis de aplicativo, proxy e consulta. O isolamento da carga de trabalho roteia o tráfego de baixa e alta prioridade para instâncias separadas, garantindo que um novo recurso mal otimizado não possa degradar os serviços principais.
Revise e monitore SQL gerado por ORM em produção. Estruturas de mapeamento objeto-relacional (ORM), como Django, SQLAlchemy e Hibernate, geram automaticamente consultas de banco de dados a partir do código do aplicativo, o que é conveniente para desenvolvedores. No entanto, a OpenAI encontrou uma consulta gerada por ORM unindo 12 tabelas que causou vários incidentes de alta gravidade quando o tráfego aumentou. A conveniência de permitir que estruturas gerem SQL cria riscos ocultos de escalabilidade que só surgem sob carga de produção. Faça da revisão dessas consultas uma prática padrão.
Aplicar disciplina operacional rigorosa. OpenAI permite apenas alterações leves de esquema – qualquer coisa que acione uma reescrita completa da tabela é proibida. As alterações de esquema têm um tempo limite de 5 segundos. Consultas de longa duração são encerradas automaticamente para evitar o bloqueio de operações de manutenção do banco de dados. Ao preencher os dados, eles impõem limites de taxas tão agressivos que as operações podem levar mais de uma semana.
Cargas de trabalho de leitura pesada com gravações intermitentes podem ser executadas no PostgreSQL primário único por mais tempo do que normalmente se supõe. A decisão de fragmentar deve depender dos padrões de carga de trabalho e não da contagem de usuários.
Esta abordagem é particularmente relevante para aplicações de IA, que muitas vezes têm cargas de trabalho fortemente orientadas para leitura com picos de tráfego imprevisíveis. Essas características se alinham com o padrão em que o PostgreSQL primário único é dimensionado de maneira eficaz.
A lição é simples: identifique os gargalos reais, otimize a infraestrutura comprovada sempre que possível e migre seletivamente quando necessário. A rearquitetura por atacado nem sempre é a resposta para os desafios de expansão.
