PGlite leva PostgreSQL para dentro do agente, mas quem é dono da verdade?

A aquisição da Electric pela Databricks acende uma pergunta arquitetural: se cada agente de IA↳Agentes de IA42 conteúdosOpera passa a integrar ChatGPT, Claude e outros agentes de IADev (Back & Front) · mar 2026Operações mais inteligentes, decisões mais rápidas: o impacto da IA agêntica na rotina de TIAI · abr 2026Adobe aposta em orquestração de agentes de IA: o que muda para devsDev (Back & Front) · abr 2026Ver tudo em AI → carrega seu próprio banco, qual instância é a fonte autoritativa dos dados.

A Databricks adquiriu a Electric, empresa por trás do PGlite, um build do PostgreSQL↳PostgreSQL11 conteúdosPostgreSQL via SSL com GolangData · abr 20195 itens legais sobre data types do PostgreSQLData · mar 20195 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → compilado para WebAssembly capaz de rodar dentro de um navegador, de um processo de aplicação, de um ambiente serverless ou de um sandbox de agente de IA. Os números de adoção impressionam: segundo o texto de Vibhor Kumar no Planet PostgreSQL, o PGlite saltou de 1 milhão para 13 milhões de downloads semanais em cerca de 12 meses. A base técnica veio do trabalho de PostgreSQL-para-WASM iniciado por Stas Kelvich, cofundador da Neon.

A manchete, porém, não é a compra. É o novo papel arquitetural que o PostgreSQL passa a ocupar. Durante praticamente toda a sua história, o Postgres foi servidor: a aplicação conecta pela rede, executa transações e depende dele como sistema de registro durável. O PGlite abre outra possibilidade, colocar o banco dentro da própria aplicação, ou dentro do próprio agente. E isso levanta a pergunta que dá título ao artigo original e que eu considero a mais séria de toda essa discussão: se todo agente tem um banco, qual banco é dono da verdade?

Por que agente é um problema de estado diferente

Aplicações tradicionais têm caminhos de execução conhecidos. As queries são projetadas de antemão, os padrões de acesso a dados podem ser testados, a infraestrutura é relativamente estável. É o mundo em que um DBA sabe onde colocar o índice porque conhece o plano de execução.

Agente não se comporta assim. Ele decide em tempo de execução qual informação precisa, quais ferramentas invocar, quais resultados intermediários reter. Recupera documentos, gera embeddings, monta um plano, chama sistemas externos, revisa suas premissas e coordena com outros agentes. Tudo isso produz estado, e é aqui que mora o incômodo de quem cuida de integridade de dados: parte desse estado é descartável, parte precisa sobreviver à sessão, parte precisa ser compartilhada com outros agentes e parte pode, eventualmente, virar registro corporativo.

Mandar cada operação intermediária para um banco remoto adiciona latência e acoplamento desnecessário. Manter tudo dentro do sandbox do agente cria ilhas isoladas de estado, difíceis de governar, reconciliar ou auditar. O PGlite entrega ao agente um PostgreSQL local, colado no ponto de execução, removendo o round trip de rede para operações de contexto local. A tecnologia de sincronização da Electric pretende ligar esse estado local distribuído a uma infraestrutura central de PostgreSQL. A Databricks descreve a combinação como estender o Postgres do lakehouse até a borda: PGlite no sandbox, um Lakebase PostgreSQL central provendo estado compartilhado e controle.

O padrão é sedutor. Mas autonomia local e autoridade corporativa não são a mesma coisa, e é exatamente aí que eu peço cautela.

Um padrão PostgreSQL, três responsabilidades diferentes

É preciso deixar claro o que o PGlite é e o que ele não é. Não se trata de um banco JavaScript↳JavaScript116 conteúdosJavaScript em 2020: O que esperarDev (Back & Front) · jan 2020Campos públicos e privados em classes JavaScript – O que vem por aí no ESNextDev (Back & Front) · abr 201929 anos de JavaScript!Dev (Back & Front) · jan 2025Ver tudo em Dev (Back & Front) → que imita a sintaxe do PostgreSQL. É o PostgreSQL compilado para WebAssembly, empacotado para ambientes JavaScript, capaz de operar em memória ou com persistência local, e com suporte a extensões, incluindo o pgvector. Isso permite ao agente combinar dados relacionais, metadados, busca full-text e recuperação vetorial no mesmo ambiente local.

Há, porém, uma limitação que muda tudo na hora de classificar responsabilidades: o PGlite roda em modo single-user, um processo e uma conexão. Suporte a múltiplas conexões segue como plano, porque o WebAssembly não oferece o modelo de fork que o PostgreSQL usa para backends concorrentes. Traduzindo para a linguagem de quem opera banco: isso é um store de execução local do agente, não um sistema de registro compartilhado.

Kumar propõe separar o estado do agente em três categorias, e eu adoto a divisão integralmente porque ela resolve boa parte da confusão:

A distinção importa por um motivo técnico preciso: o PostgreSQL garante integridade transacional dentro de um sandbox local, mas isso não garante automaticamente correção entre milhares de agentes operando de forma independente. Usar Postgres nas duas pontas não torna as duas instâncias intercambiáveis. Um agente pode consumir ou propor mudanças ao estado autoritativo, mas seu banco local não pode se tornar silenciosamente uma fonte alternativa de verdade.

Sincronização é o problema de sistemas de verdade

Rodar PostgreSQL em WebAssembly é tecnicamente fascinante. Sincronizar uma frota de ambientes PostgreSQL distribuídos é o desafio arquitetural profundo, e é onde a euforia costuma esbarrar na realidade. As perguntas que Kumar enumera são exatamente as que eu faria num review de arquitetura:

• O que acontece quando dois agentes atualizam a mesma entidade?
• E se um agente continua trabalhando depois de ter a autorização revogada no centro?
• Uma transação gerada localmente pode ser reexecutada com segurança após uma queda de rede?
• Quais operações toleram consistência eventual e quais exigem aprovação central antes de executar?
• Como mudanças de schema e de política se propagam para os sandboxes ativos?

Há um ponto que merece destaque: a sincronização precisa carregar mais do que linhas. O agente precisa do dado, mas também do contexto de autorização e política que governa como aquele dado pode ser usado. Se o dado se move sem seus controles, a sincronização reproduz a informação enquanto enfraquece o seu significado. Para quem trabalha com governança, essa frase deveria ser afixada na parede.

E convém temperar o entusiasmo com o estado real da implementação. O plugin de sincronização documentado do PGlite é descrito como alpha, com limitações em sincronização de escritas locais de saída e em resolução de conflitos. O motor de sync da Electric tem mais recursos, mas a documentação lembra que a visão arquitetural está à frente de partes da engenharia.

O caso que resume o risco

Kumar traz um exemplo concreto que vale reproduzir porque ilustra por que banco local não basta. Considere um agente que confirma uma transação localmente, invoca um serviço externo e perde conectividade antes de sincronizar seu estado com o centro. Quando a tarefa retoma, o agente pode não saber se a ação externa foi concluída. Repeti-la pode cobrar o cliente duas vezes, submeter o mesmo pedido de novo ou executar uma segunda mudança de infraestrutura. Kumar chama o conjunto de práticas que ele recomenda para esse tipo de cenário de ORBIT, framework de princípios de execução confiável que ele detalha na mesma publicação; sobre o caso específico, ele resume:

O PostgreSQL pode proteger a transação local. O ORBIT é sobre proteger o resultado de ponta a ponta.

Vibhor Kumar

É o velho padrão que todo mundo que já implementou integração confiável conhece: o Outbox primeiro, registrando a intenção durável de forma transacional antes de sincronizar ou chamar o sistema externo, e idempotência antes do dia um, para que retries e eventos reexecutados não repitam a ação de negócio subjacente. Nada disso é novidade conceitual, mas a arquitetura de agente com banco local multiplica os pontos onde a disciplina precisa ser aplicada.

Meu contra-argumento, e por que ainda sustento a posição

O argumento mais forte contra a minha cautela é legítimo: colocar o Postgres perto do agente reduz latência, remove acoplamento com o banco central em operações de contexto local e reaproveita todo o conhecimento acumulado de SQL, schemas, tipos, transações e extensões. Menos traduções entre ambientes significa menos erros de integração. Isso é alavancagem real, e eu não vou fingir que não é.

Mas alavancagem não é uniformidade. A mesma fundação PostgreSQL nas duas pontas pode, e deve, sustentar responsabilidades operacionais diferentes. O ganho de produtividade não autoriza tratar a instância local como sistema de registro só porque fala o mesmo dialeto SQL. A tentação de deixar o estado autoritativo escorregar para dentro do sandbox, por conveniência, é justamente o que produz fragmentação de verdade e conflito de dados distribuídos. Quanto mais autonomia se dá ao agente, mais precisamente é preciso definir suas fronteiras.

Para o time brasileiro que está montando arquitetura de agentes agora, o recado prático é direto: antes de adotar PGlite, decida em qual das três categorias cada dado se encaixa, defina qual instância é autoritativa para cada classe de estado, e trate a sincronização como projeto de sistemas, com lineage capaz de responder não só o que o agente fez, mas o que ele sabia, sob qual política, quando decidiu agir. A pergunta que fica não é quantos bancos PostgreSQL conseguimos criar. É se conseguimos preservar uma fronteira clara entre o estado que o agente pode usar, o que ele pode mudar e a verdade que a empresa está disposta a confiar.

Fonte 1: Planet PostgreSQL (https://postgr.es/p/9sG)

Every AI Agent May Need PostgreSQL. Not Every Agent Should Own the Truth. – Vibhor Kumar

Fonte: Planet PostgreSQL