Toda revisão de arquitetura em um projeto de IA agêntica termina na mesma pergunta: a pilha que já temos pode dar suporte ao que vamos construir? É tentador responder a essa pergunta comparando o desempenho dos bancos de dados vetoriais. A questão mais profunda é se sua arquitetura pode dar as respostas a perguntas sobre dados e o significado na mesma consulta, com as mesmas garantias.

É isso que um agente realmente precisa. É a parte da pilha que a maioria das equipes resolve por último, depois que o resto do sistema já ganhou forma. O banco de dados operacional é tratado como um dado. De acordo com a Harvard Business Review Analytic Services, apenas 15% das organizações consideram sua base de dados pronta para a IA agêntica. O resultado é uma arquitetura dividida que parece razoável no rascunho e começa a desmoronar na produção.

Vale a pena comparar honestamente os dois padrões:

• Arquitetura unificada: uma única plataforma lida com dados operacionais e pesquisa vetorial em conjunto.
• Arquitetura dividida: um armazenamento vetorial dedicado (Pinecone, Weaviate ou um mecanismo de pesquisa como Elasticsearch) fica ao lado do banco de dados operacional, com um pipeline ETL mantendo os dois sincronizados.

Desconstruindo o ciclo viral da migração do Postgres

A cada poucos meses, uma publicação no blog familiar se torna viral no ecossistema de desenvolvedores: “Por que voltamos para o Postgres.” Quase instantaneamente, os tópicos de comentários são preenchidos com exatamente os mesmos pontos de conversa previsíveis: o MongoDB não é possível dimensionar, não há ingressos e as transações são fracas. Tim Carter Clausen, que grava como The Decipherist e executa a MongoDB em produção há uma década, aborda cada crítica diretamente, com dados de produção do mundo real ao seu lado.

Escolher um banco de dados com um modelo de dados que corresponda ao restante da pilha garante que sua velocidade de engenharia não seja prejudicada por limitações arquitetônicas.

Aprofundamento: o custo da taxa de tradução de SQL

Uma típica solicitação SQL faz oito alterações de formato em uma única viagem de ida e volta:

1. O cliente envia JSON.
2. A API analisa um objeto JavaScript.
3. Uma ferramenta ORM decompõe esse objeto em linhas espalhadas por tabelas normalizadas.
4. O banco de dados faz seu trabalho.
5. As linhas são remontadas.
6. São mapeadas de volta em um objeto.
7. O objeto é serializado de volta para JSON.
8. A resposta foi enviada.

O equivalente do MongoDB são quatro transformações, e Clausen afirma que quatro é um exagero, pois a forma dos dados nunca muda de fato. Cada alteração de formato no caminho do SQL consome CPU e memória, introduz latência e oferece um lugar onde um erro pode se esconder.

A realidade das atualizações de esquema

Renomear um campo, adicionar um objeto aninhado ou reestruturar um documento acontece ao vivo no MongoDB, com tempo de inatividade zero. A mesma operação em uma grande tabela relacional pode causar bloqueio ao gravar por minutos ou até horas. Para equipes que lançam semanalmente, a diferença não é teórica. É a diferença entre adicionar um campo à tarde e agendar um período de manutenção no próximo trimestre.

O imposto latente na camada de indexação

A mesma divergência arquitetônica aparece na camada de indexação. Considere uma consulta familiar para alguém que administra um sistema operacional: devolva os últimos 10 pedidos de um determinado produto em um determinado país.

• No modelo de documento: um único índice composto serve isso diretamente, incluindo os campos aninhados dentro de arrays.
• Em um sistema relacional (JSONB): O equivalente normalmente exige um índice GIN para o conteúdo do array, um índice separado de B-tree para os campos escalares e uma ordenação pesada que o planejador de query não consegue evitar. O plano lê mais linhas do que o necessário, apresentando dimensionamento desfavorável à medida que os dados aumentam. Nada disso é visível na camada de aplicativo, mas tudo isso é visível na sua fatura da nuvem.

O poder estruturante da localização de dados

A perspicácia estrutural por trás de ambos os pontos é a localidade dos dados. No modelo de documento, o modelo lógico e o modelo físico são idênticos. A forma que a aplicação grava é a forma exata que o banco de dados armazena, e a forma que o banco de dados armazena é a forma exata que a camada de recuperação retorna a um agente de IA. Essa equivalência elimina completamente os pipelines de sincronização, a lógica de gravar dupla e as tarefas complexas de reconciliação que as arquiteturas fragmentadas precisam para alcançar o mesmo resultado.

Framework de decisão de um arquiteto

O framework de decisão de Pachot aponta para estas realidades técnicas:

• Escolha relacional (Postgres): para um banco de dados centralizado que atende a muitos aplicativos diferentes, onde os casos de uso finais ainda não são todos conhecidos.
• Escolha documento (MongoDB): para um único aplicativo criado a partir de um modelo de domínio e persistido exatamente como o aplicativo o interpreta.

A pergunta que vale a pena fazer em seguida é qual delas descreve o trabalho que você está criando em 2026: microsserviços com contextos limitados, esquemas que iteram semanalmente ou objetos de domínio persistidos da forma como seu aplicativo naturalmente pensa sobre eles?

“Um banco de dados é bom e rápido se você o usar corretamente, e o mais importante é escolher um que você conhece ou que quer aprender.”
— Franck Pachot, AWS Data Hero & Oracle Certified Master

Assista à palestra