Banco de dados vetorial: pgvector, Qdrant ou Weaviate

Banco de dados vetorial é um dos termos que mais aparecem sem necessidade nesse momento de hype de IA generativa aplicada. Quase todo projeto de RAG que chega na minha mesa começa com a pergunta de qual ferramenta vetorial usar, antes de alguém parar pra perguntar se o projeto realmente precisa de uma. Já subi pgvector em produção, testei Qdrant em container no meu homelab e passei um fim de semana comparando latência de busca com Weaviate. Esse texto é o resumo direto do que aprendi nesse caminho todo: quando cada banco de dados vetorial faz sentido, e quando você está complicando um problema que um índice comum já resolveria.

O que é um banco de dados vetorial e por que ele importa

Um banco de dados vetorial guarda representações numéricas de texto, imagem ou áudio (os chamados embeddings) e permite buscar por similaridade em vez de por igualdade exata.

Isso importa porque é a peça que sustenta boa parte dos sistemas de RAG. Sem busca vetorial eficiente, seu agente não encontra o trecho certo do documento pra responder a pergunta do usuário.

Na minha visão, o erro comum é tratar isso como uma decisão de arquitetura enorme. Na prática, é só mais um componente de armazenamento com uma característica específica: busca por proximidade.

Quando você realmente precisa de um banco de dados vetorial

Nem todo projeto de IA precisa de um banco de dados vetorial dedicado. Alguns sinais claros de que vale a pena:

• Sua base de conhecimento passa de alguns milhares de documentos e cresce todo mês.
• Você já tem um pipeline de RAG funcionando e a busca por palavra-chave não dá conta da semântica.
• Precisa filtrar resultados por metadado (data, categoria, usuário) junto com a busca semântica.
• A latência da busca já virou gargalo visível pro usuário final.

Se nenhum desses cenários bate com sua realidade, guarda os embeddings numa tabela normal e resolve com busca por texto mesmo. Show, resolve, sem drama.

Como pgvector, Qdrant e Weaviate funcionam na prática

pgvector: vetorial dentro do Postgres que você já tem

O pgvector é uma extensão do PostgreSQL. Ele adiciona um tipo de coluna vetorial e índices de similaridade dentro do banco relacional que provavelmente já roda no seu projeto.

A vantagem é óbvia: zero infraestrutura nova. Você já tem backup, replicação e monitoramento configurados pro Postgres, e o vetorial fica ali dentro, junto dos dados relacionais.

O ponto fraco aparece em escala grande. Acima de alguns milhões de vetores, a performance de índice do pgvector fica atrás de soluções feitas só pra isso.

Qdrant: banco vetorial dedicado, leve pra rodar em container

Qdrant é escrito em Rust, sobe rápido em Docker e tem uma API simples pra busca e filtro combinado. É a opção que eu mais recomendo quando o time já opera containers e quer controle total sobre o dado.

Na prática, o Qdrant lida bem com filtros complexos por metadado sem perder muito desempenho, o que é um problema real em muitos sistemas de busca vetorial mal desenhados.

Weaviate: mais recursos, mais operação

Weaviate entrega mais funcionalidades prontas: módulos de vetorização embutidos, busca híbrida nativa, suporte a múltiplos esquemas de dados na mesma instância.

O custo disso é operacional. Weaviate exige mais memória e mais atenção de configuração do que Qdrant pra rodar de forma estável em produção. Não é ruim, é só mais peso.

pgvector vs Qdrant vs Weaviate: quando escolher cada um

Quando seu volume de dados é modesto e você já tem Postgres rodando, pgvector resolve sem adicionar mais uma peça na sua stack. É a escolha mais simples e, na minha visão, a mais subestimada.

Quando você precisa de performance de busca dedicada, com filtros por metadado e volume crescendo rápido, Qdrant entrega o equilíbrio certo entre simplicidade operacional e capacidade real.

Quando o projeto pede recursos avançados prontos, como busca híbrida nativa ou múltiplos esquemas complexos, e o time tem gente disponível pra operar mais uma peça de infraestrutura, Weaviate faz sentido.

Fora desses cenários específicos, não vale complicar. Um banco de dados vetorial dedicado não é sinônimo de sistema melhor, é só uma ferramenta com um trade-off específico.

O custo de escolher errado o banco de dados vetorial

Escolher a ferramenta errada aqui não quebra o projeto no dia seguinte. O problema aparece meses depois, quando a base cresceu e a migração já não é trivial.

Já vi time gastar semana inteira migrando de uma solução vetorial pra outra porque escolheu a ferramenta mais badalada do momento sem medir volume real de dados nem padrão de consulta.

O impacto concreto costuma ser: latência de busca subindo, custo de infraestrutura maior do que o necessário, e um time reescrevendo consultas que já estavam funcionando.

Como validar a escolha antes de comprometer o projeto

Antes de decidir, peça pra IA te ajudar a estimar volume esperado de vetores, frequência de escrita e tipo de filtro que você vai precisar combinar com a busca semântica.

Descreva pra ela o cenário real do seu projeto (quantidade de documentos, taxa de crescimento, se já usa Postgres) e peça uma comparação objetiva entre as opções, não uma recomendação genérica.

Valide a resposta olhando três coisas: se ela considerou seu volume real, se mencionou o custo operacional de manter mais um serviço rodando, e se apontou claramente o cenário em que a recomendação deixa de valer.

Se a resposta parecer vender uma ferramenta sem mencionar nenhuma limitação, desconfie. Toda ferramenta vetorial tem limitação, e uma IA que não menciona nenhuma provavelmente só repetiu marketing.

Perguntas frequentes sobre banco de dados vetorial

Pgvector aguenta produção com muito volume?

Aguenta até um volume considerável, geralmente na casa de alguns milhões de vetores, dependendo do hardware e do índice usado. Acima disso, o desempenho de busca costuma cair em relação a soluções dedicadas.

Preciso de Qdrant ou Weaviate se já uso Postgres?

Não necessariamente. Se o volume é moderado e você já opera Postgres, pgvector evita adicionar mais um serviço pra manter. A troca só compensa quando a performance ou os recursos específicos justificam.

Banco de dados vetorial substitui um pipeline de RAG completo?

Não. Ele é só a camada de armazenamento e busca. O pipeline de RAG inclui também extração de conteúdo, geração dos embeddings e a etapa de gerar a resposta final com o modelo de linguagem.

Dá pra migrar de um banco vetorial para outro depois?

Dá, mas custa tempo de engenharia. Regerar embeddings, reindexar e ajustar consultas não é instantâneo. Por isso vale medir volume e padrão de uso antes de comprometer a arquitetura.

O modelo de vetorização importa mais do que o banco escolhido?

Em muitos casos sim. Um modelo de embedding ruim gera busca ruim independente do banco de dados vetorial usado. Vale testar qualidade de recuperação antes de otimizar a camada de armazenamento.

Conclusão

Banco de dados vetorial não é decisão de moda, é decisão de volume e padrão de consulta. Comece pelo pgvector se já tem Postgres rodando, migre pra Qdrant quando a performance pedir, e só considere Weaviate se o time tem estrutura pra operar mais uma peça de infraestrutura.

Se você já roda seus modelos localmente, dá uma olhada em como rodar modelos de linguagem no seu próprio ambiente antes de decidir onde guardar os vetores gerados por eles. E se o plano é expor esse serviço vetorial de forma segura, vale entender como colocar um reverse proxy na frente da aplicação.

Pra quem já opera em produção, também recomendo registrar como está o comportamento das buscas com uma ferramenta de rastreamento de chamadas de LLM em produção, porque busca vetorial ruim costuma aparecer primeiro nos logs de qualidade de resposta.

Pra referência técnica oficial sobre filtros, índices e configuração de coleções, vale consultar a documentação oficial do Qdrant.

Se seu volume ainda é pequeno, comece simples e migra quando os números pedirem. Se já é grande, teste as três opções com dado real antes de comprometer a arquitetura inteira do seu sistema de IA.