Banco vetorial: pgvector, Qdrant ou serviço gerenciado?

Banco vetorial: pgvector, Qdrant ou serviço gerenciado?

Para quem já usa Postgres, o caminho mais sensato costuma ser começar com pgvector: você reaproveita backup, acesso, monitoramento e a equipe que já existe. Qdrant passa a fazer sentido quando a busca vetorial vira uma carga própria, com muito volume, filtros complexos ou necessidade de isolar desempenho. Serviço gerenciado vale quando a empresa não quer operar nada e aceita depender de um fornecedor.

Principais pontos

• Se você já tem Postgres e o conjunto de documentos é de pequeno a médio, pgvector é o ponto de partida com menor custo de operação.
• Qdrant compensa quando a busca vetorial pesa no banco principal, quando os filtros são sofisticados ou quando você quer escalar a busca separada do transacional.
• Serviço gerenciado troca trabalho de operação por dependência de fornecedor e por uma fatura que cresce com o uso.
• Filtro por permissão é o requisito que mais decide a arquitetura: quem não pode ver um documento nunca deve recebê-lo no contexto do modelo.
• O custo real é a manutenção: atualização, reindexação, backup, monitoramento e quem atende o alerta de madrugada.

O que um banco vetorial resolve e o que ele não resolve

Um banco vetorial guarda representações numéricas (embeddings) de textos e permite buscar o que é semanticamente parecido com uma pergunta. Ele é a peça de recuperação de uma arquitetura de RAG, em que o sistema busca trechos relevantes e os entrega ao modelo para responder com base neles. A AWS descreve o RAG justamente como essa combinação de recuperação e geração.

O que ele não resolve: qualidade dos documentos, divisão dos textos em trechos, regras de acesso e avaliação das respostas. Muita empresa gasta semanas comparando bancos quando o problema real é um manual desatualizado ou um trecho cortado no meio de uma regra. Antes de escolher a tecnologia, vale olhar o desenho completo, como mostra a arquitetura de referência de RAG do Google Cloud: ingestão, indexação, recuperação, geração e controle.

A pergunta de negócio vem antes da de tecnologia: que decisão ou atendimento essa busca vai apoiar, quem pode ver cada informação e o que acontece quando a resposta vem errada?

pgvector: quando o Postgres que você já tem basta

pgvector é uma extensão do Postgres que adiciona o tipo vetor e operações de similaridade. Ela oferece índices aproximados, como HNSW e IVFFlat, que trocam um pouco de exatidão por velocidade. Para muitos casos de empresa (base de conhecimento interna, atendimento, propostas, contratos), isso é suficiente.

Vantagens práticas para quem já roda Postgres:

• Um sistema só: dados de negócio, metadados e vetores na mesma transação e no mesmo backup.
• Filtros em SQL comuns: permissão, cliente, unidade, status e data viram cláusulas WHERE e junções que a equipe já domina.
• Segurança conhecida: papéis, esquemas e, quando fizer sentido, políticas de segurança por linha (row level security) do próprio Postgres.
• Menos superfície para auditar, o que ajuda em conversas sobre LGPD e em um RIPD quando o projeto trata dados pessoais.

Limites a respeitar: busca vetorial consome memória e processamento, e disputa recursos com o banco transacional se estiverem na mesma instância. Índices aproximados com filtros muito restritivos podem devolver menos resultados do que o esperado, dependendo da versão e da configuração. Isso não é motivo para descartar a opção, é motivo para testar com os filtros reais do seu caso. Uma réplica de leitura ou uma instância separada só para a busca costuma resolver a disputa de recursos sem trocar de tecnologia.

Qdrant: quando a busca vira uma carga própria

Qdrant é um banco vetorial de código aberto, que pode rodar em servidor próprio ou como serviço da própria empresa que o mantém. Ele foi desenhado para busca vetorial com filtros sobre metadados (o payload), e isso aparece no dia a dia: filtrar por atributos durante a busca é parte central do produto, não um acessório.

Quando faz sentido considerar Qdrant:

• O volume de vetores cresce a ponto de a busca competir com o Postgres principal.
• Os filtros são numerosos e combinados (unidade, perfil de acesso, idioma, validade, tipo de documento).
• Você precisa escalar e ajustar a busca de forma independente do restante do sistema.
• Há mais de um produto ou agente consumindo a mesma camada de recuperação.

O preço é operacional. Você passa a ter mais um serviço para implantar, atualizar, proteger, monitorar e restaurar. Também passa a existir a sincronização: o documento mudou no sistema de origem, o vetor precisa mudar no Qdrant, e alguém precisa garantir que isso aconteça e que registros apagados sumam de verdade. Para empresas com LGPD no radar, o apagamento a pedido do titular precisa alcançar os dois lugares.

Serviço gerenciado: o que você compra e o que continua sendo seu

Serviço gerenciado pode ser um banco vetorial em nuvem, uma oferta do seu provedor (busca vetorial dentro da plataforma de nuvem que você já usa) ou a versão hospedada de um produto de código aberto. Você compra principalmente tempo: provisionamento, atualização, alta disponibilidade e escala deixam de ser tarefa da sua equipe.

O que continua sendo seu, qualquer que seja o fornecedor:

• A regra de quem pode ver o quê e a garantia de que ela é aplicada em toda consulta.
• A qualidade e a atualização dos documentos indexados.
• A avaliação das respostas e o monitoramento de qualidade.
• A conformidade: contrato de tratamento de dados, local de armazenamento, subprocessadores e transferência internacional, que a ANPD acompanha.

Os riscos específicos são a dependência (migrar depois exige reindexar e adaptar consultas), a fatura que acompanha o uso e a menor visibilidade sobre o que acontece por dentro. Para uma empresa sem ninguém que queira cuidar de infraestrutura, pode ser a escolha correta. Só convém decidir isso com os olhos abertos, e não por ser a opção que parece mais simples na primeira semana.

Como tratar filtros por permissão sem vazar documento

Esse é o ponto em que projetos de RAG mais erram. Se o assistente interno responde com um trecho de um documento que o usuário não deveria ver, o dano já aconteceu: não adianta pedir ao modelo para esconder depois. A regra de acesso precisa ser aplicada antes de o texto chegar ao contexto, e não na instrução do prompt. O guia de autorização da OWASP reforça princípios que valem aqui: negar por padrão, verificar em toda requisição e aplicar o menor privilégio.

Um desenho seguro costuma seguir estes passos:

• Cada trecho indexado carrega metadados de acesso (grupo, unidade, cliente ou nível de confidencialidade) herdados do documento de origem.
• A identidade do usuário vem do sistema de autenticação da empresa, nunca de algo que o usuário digite na conversa.
• A consulta de busca sempre inclui o filtro de permissão, montado pelo código da aplicação e não pelo modelo.
• Documentos sem classificação ficam de fora por padrão.
• Mudanças de permissão na origem atualizam o índice, com prazo definido para isso acontecer.
• Os testes incluem tentativas de acesso indevido, e os logs registram quais trechos foram entregues a quem.

Como cada opção ajuda nisso: no pgvector, o filtro pode ser uma junção com tabelas de permissão que você já mantém, e políticas por linha dão uma segunda barreira. No Qdrant, o filtro por payload é natural, mas a fonte da verdade sobre permissões continua fora dele, então a sincronização é o ponto crítico. Em serviço gerenciado, vale conferir como o filtro é aplicado, se há isolamento por namespace ou por coleção e como o acesso é auditado. Qualquer que seja a escolha, guardrails na entrada e na saída ajudam, como detalhamos em guardrails para agentes de IA, mas não substituem o filtro na consulta.

Custo de manutenção: o que pesar além da fatura

A comparação ingênua olha o preço de infraestrutura. A comparação útil olha o custo por unidade de valor entregue, a lógica de unit economics do FinOps: quanto custa manter a busca funcionando para cada fluxo de negócio que ela atende.

Itens que costumam ficar fora da conta inicial:

• Reindexação quando você troca o modelo de embeddings (os vetores antigos deixam de ser comparáveis com os novos).
• Atualização de versões, extensões e índices.
• Backup, restauração testada e plano para incidente.
• Monitoramento de latência, uso de memória e qualidade das buscas, com a mesma disciplina de qualquer sistema em produção (os conceitos de observabilidade do OpenTelemetry valem aqui).
• Pessoa responsável. Um componente sem dono vira risco, não importa onde esteja hospedado.
• Custo de saída: o esforço de migrar para outra opção no futuro.

Na prática, pgvector tende a ter o menor custo incremental para quem já tem equipe de Postgres, porque a manutenção se soma a rotinas existentes. Qdrant próprio exige uma rotina nova. Serviço gerenciado reduz a rotina, mas a conta passa a depender do uso e do contrato.

Como decidir e pilotar sem apostar tudo

Um guia de decisão simples para quem já usa Postgres:

• Já tem Postgres bem operado, base de tamanho moderado e filtros por permissão ligados ao seu banco: comece com pgvector.
• A busca está pesando no banco principal, mas a equipe sabe operar infraestrutura: considere separar em uma instância Postgres dedicada antes de trocar de tecnologia.
• Os filtros são complexos, o volume cresce e vários sistemas consomem a busca: avalie Qdrant, com responsável definido pela sincronização.
• Não há equipe para operar e a empresa aceita dependência: avalie serviço gerenciado, com atenção a contrato de dados, local de armazenamento e custo de saída.
• Dados sensíveis ou sob sigilo forte: priorize a opção em que você controla onde os dados ficam e que é mais fácil de auditar.

Cenário ilustrativo: uma distribuidora com Postgres já em produção quer um assistente que responda dúvidas de vendedores sobre políticas comerciais e fichas técnicas, com regras diferentes por região. Os documentos são poucos e mudam algumas vezes por mês. Aqui, pgvector com uma coluna de região e de perfil em cada trecho resolve o filtro com SQL comum, sem novo serviço. Se, meses depois, o assistente passar a atender também o suporte e o jurídico, com muito mais documentos e acessos simultâneos, a equipe já terá métricas reais para avaliar se separar a busca em Qdrant ou em um serviço gerenciado se justifica.

O método que aplicamos é o mesmo para qualquer uma das três opções. Mapear: documentos, donos, regras de acesso e o fluxo que a busca vai apoiar, com um ponto de partida medido. Limitar: quais dados entram no índice e que ações o agente pode tomar a partir das respostas. Pilotar: um fluxo real, com logs de cada trecho recuperado e uma métrica de sucesso combinada de antemão (veja como medir um piloto de automação com IA). Transferir: documentar a operação, definir o responsável e decidir se expande, ajusta ou para. Se o assistente for atender por WhatsApp, a camada de recuperação é só uma parte, e o guia de integração de IA no WhatsApp cobre o restante do desenho.

Uma regra prática de migração: mantenha o texto original e os metadados sempre no sistema de origem, e trate o índice vetorial como algo que pode ser reconstruído. Assim, trocar de pgvector para Qdrant ou para um serviço gerenciado vira uma reindexação planejada, e não uma perda de dados.

Perguntas frequentes

Posso começar com pgvector e migrar depois? Sim, e é uma estratégia comum. Se o texto original e os metadados ficam no sistema de origem e o índice é reconstruível, a migração é uma reindexação e uma adaptação das consultas. O que pede cuidado é manter a lógica de permissão em uma camada da aplicação, e não espalhada em consultas difíceis de portar.

Qdrant é mais rápido que pgvector? Depende do volume, dos filtros, da configuração e do hardware, então não há resposta geral confiável. Em bases menores, a diferença costuma não aparecer para o usuário final. Teste com seus documentos, seus filtros e o tráfego esperado, e meça latência e qualidade dos resultados, não só velocidade.

Serviço gerenciado resolve a conformidade com a LGPD? Não por si só. O fornecedor cuida de parte da infraestrutura, mas a empresa continua responsável pela finalidade, pela base legal, pelo controle de acesso e pelo atendimento a pedidos de titulares. Confira contrato de tratamento, local de armazenamento e subprocessadores, e acompanhe o que a empresa deve observar em marco legal da IA no Brasil.

O banco vetorial é o que mais influencia a qualidade das respostas? Raramente. A qualidade vem mais da boa divisão dos documentos, de conteúdo atualizado, de um bom modelo de embeddings, de filtros corretos e de avaliação contínua com perguntas reais. Trocar de banco sem corrigir esses pontos costuma mudar pouco o resultado.

Fontes

• AWS: What is retrieval-augmented generation
• Google Cloud: retrieval-augmented generation architecture
• OWASP: authorization guidance
• FinOps Foundation: unit economics