Quando comecei a construir o pipeline RAG para o meu sistema de automação de suporte, perdi muito tempo lendo comparações de benchmarks. Cada artigo tinha tabelas com números impressionantes — latências P95, métricas de QPS, uso de memória por milhão de vetores. O que descobri depois de colocar em produção é que esses benchmarks quase nunca preveem o comportamento real no seu ambiente específico.
O que realmente importa é: como esse banco de dados se encaixa na sua infraestrutura? Como ele falha? O que acontece quando você precisa atualizar embeddings às 2 da manhã? Essas perguntas não aparecem em tabelas de comparação.
Este post compartilha o que aprendi construindo e operando um sistema de busca vetorial em produção — a espinha dorsal do RAG de um pipeline de automação de suporte que processa centenas de tickets por dia.
O Sistema que Construí
O sistema de automação de suporte que vou referenciar ao longo do post é um pipeline RAG que:
- Ingere e re-embeds documentação de suporte em uma programação noturna
- Fornece resultados de busca semântica para um agente de triagem que roteia e rascunha respostas a tickets
- Lida com padrões de carga em picos (tickets se concentram em horários comerciais)
Esse contexto importa porque minhas escolhas foram moldadas por ele. Um sistema que faz busca de similaridade de imagens em tempo real chegaria a respostas diferentes.
Entendendo o que Bancos de Dados Vetoriais Realmente Fazem
Antes de comparar opções, vale ser preciso sobre o que um banco de dados vetorial oferece que um banco de dados comum não oferece.
Quando você embute um texto com um modelo como claude-haiku-4-5-20251001 ou um modelo de embedding dedicado, você obtém um array de floats de alta dimensão — tipicamente 256 a 3072 dimensões dependendo do modelo. Um banco de dados vetorial armazena esses arrays e responde à pergunta: "dado esse vetor de consulta, quais vetores armazenados são mais similares?"
A operação principal é a busca aproximada por vizinhos mais próximos (ANN). "Aproximada" é a palavra-chave — para grandes coleções, a busca exata é muito lenta, então esses sistemas trocam um pouco de precisão de recall por grandes ganhos de velocidade usando estruturas de indexação como HNSW (Hierarchical Navigable Small World graphs).
Aqui está um padrão mínimo de embedding + busca usando pgvector, que é o que o meu sistema de automação de suporte utiliza:
O operador <=> é o operador de distância de cosseno do pgvector. O índice faz o trabalho pesado para evitar uma varredura completa da tabela em cada consulta.
As Opções que Avaliei
Quando estava construindo o pipeline RAG de automação de suporte, avaliei seriamente quatro opções. Aqui está minha avaliação honesta de cada uma — baseada em experiência operacional, não em benchmarks sintéticos.
pgvector
pgvector é uma extensão do PostgreSQL que adiciona um tipo vector e suporte a índices ANN. Eu o escolhi para o sistema de automação de suporte e não me arrependo.
Por que funcionou para mim: O sistema de automação de suporte já rodava Postgres. Adicionar pgvector significou um serviço a menos para operar, um ponto de falha a menos, e a capacidade de fazer consultas híbridas juntando metadados de tickets com busca semântica em uma única instrução SQL.
Onde tem dificuldades: Em escala muito grande (dezenas de milhões de vetores), o índice HNSW do pgvector tem restrições de memória. O índice vive na memória compartilhada, e você precisa ajustar maintenance_work_mem cuidadosamente durante as construções de índice. Na minha escala (centenas de milhares de docs), isso nunca foi um problema real.
Quando escolhê-lo: Você já roda Postgres, sua coleção cabe em um único nó, e você quer consistência transacional entre seus dados vetoriais e relacionais.
Pinecone
Pinecone é um banco de dados vetorial totalmente gerenciado e desenvolvido especificamente para esse fim. Ele abstrai toda a infraestrutura.
O que acerta: A simplicidade operacional é real. Não há cluster para gerenciar, sem knobs de ajuste de índice, sem dimensionamento de memória para errar. Se você é uma equipe pequena que quer publicar rapidamente e não quer pensar em operações de banco de dados vetorial, o Pinecone entrega.
Onde tem dificuldades: O modelo de serviço gerenciado significa que você depende da disponibilidade e dos preços do Pinecone. A filtragem por metadados tem limitações — você não pode fazer joins no estilo SQL. E se você precisar fazer algo fora da API de busca principal, estará trabalhando contra a corrente.
Quando escolhê-lo: Você quer simplicidade operacional acima de tudo, não precisa combinar busca vetorial com consultas relacionais, e o modelo de preços funciona para a sua escala.
Qdrant
Qdrant é um banco de dados vetorial desenvolvido especificamente, escrito em Rust, disponível tanto auto-hospedado quanto em nuvem gerenciada.
Avaliei o Qdrant seriamente porque suas capacidades de filtragem são mais expressivas do que as do Pinecone. Ele suporta árvores de filtros complexas com condições must/should/must_not, que se mapeiam bem para o tipo de filtragem de metadados estruturados que meu agente de triagem precisa.
Onde tem dificuldades: É mais um serviço para operar. Se você ainda não está containerizando e gerenciando serviços, o Qdrant adiciona overhead operacional. A opção de nuvem gerenciada ajuda, mas tem um custo.
Quando escolhê-lo: Você precisa de filtragem expressiva de metadados, está confortável com implantações baseadas em contêineres e quer mais controle do que um serviço totalmente gerenciado oferece.
Weaviate
O Weaviate tem um posicionamento único: tenta ser tanto um banco de dados vetorial quanto um grafo de conhecimento semântico, com vetorização de texto integrada e uma interface de consulta GraphQL.
Achei a API GraphQL mais complexa do que o necessário para RAG direto. Os vetorizadores integrados são convenientes se você quer que o Weaviate gerencie a geração de embeddings, mas acoplam sua escolha de modelo de embedding à escolha do banco de dados de formas que podem ser limitantes.
Quando escolhê-lo: Você quer vetorização integrada e está construindo algo que se beneficia dos recursos de grafo de conhecimento do Weaviate. Para RAG direto, opções mais simples geralmente vencem.
O Que Realmente Importa em Produção
Depois de construir e operar esse sistema por meses, aqui está o que eu diria para mim mesmo no início:
A adequação operacional supera os números de benchmark. O sistema que se encaixa na sua infraestrutura existente e nas habilidades operacionais da sua equipe vai superar um sistema "mais rápido" que introduz fricção.
O design de filtragem por metadados é crítico. Passei tempo significativo repensando meu esquema de metadados depois que a primeira versão tornava as consultas comuns mais difíceis do que deveriam ser. Pense cuidadosamente sobre o que você precisa filtrar antes de projetar seu esquema — a camada de busca vetorial deve trabalhar com sua estratégia de filtragem, não contra ela.
A escolha do modelo de embedding importa mais do que a escolha do banco de dados. Testei vários modelos de embedding antes de me decidir por um para o pipeline de automação de suporte. A qualidade da busca semântica depende muito mais de como o modelo de embedding representa seu domínio do que do algoritmo ANN que o banco de dados usa.
Os custos de re-embedding são reais. Quando você mudar os modelos de embedding (e você vai mudar em algum momento), precisará re-embedar todo o seu corpus. Projete para isso: mantenha seu texto original, rastreie qual versão do modelo de embedding foi usada e construa um pipeline de re-embedding antes de precisar dele.
Busca Híbrida: A Lacuna entre Teoria e Prática
A maioria dos sistemas RAG em produção acaba fazendo alguma forma de busca híbrida — combinando similaridade vetorial com correspondência de palavras-chave (BM25) ou filtros de metadados.
O pgvector não tem BM25 integrado, então no sistema de automação de suporte eu trato isso com uma etapa simples de reranking: recupero mais candidatos da busca vetorial e depois aplico pontuação por palavras-chave antes de retornar o conjunto final.
Esta é uma abordagem simples, mas funciona de forma confiável. Busca híbrida mais sofisticada — com indexação BM25 adequada integrada ao armazenamento vetorial — está disponível no Weaviate e no Qdrant.
Minha Recomendação por Contexto
Não existe banco de dados vetorial universalmente "melhor". Veja como eu abordaria a escolha:
Você está adicionando busca vetorial a um sistema Postgres existente: Comece com pgvector. Você obtém flexibilidade SQL, consistência transacional e simplicidade operacional. Passe para uma solução desenvolvida especificamente mais tarde, se precisar.
Você está construindo um novo serviço e quer publicar rapidamente sem gerenciar infraestrutura: Pinecone ou Qdrant Cloud. Aceite o trade-off do serviço gerenciado para mover rapidamente.
Você precisa de filtragem expressiva de metadados e está confortável com contêineres: Qdrant auto-hospedado. A API de filtros é excelente e a implementação em Rust lida bem com carga concorrente.
Sua coleção é pequena (menos de um milhão de vetores) e você precisa de joins SQL: pgvector, sem contestação.
O pipeline RAG de automação de suporte roda em pgvector. Não é a escolha mais rápida possível, mas é a escolha certa: vive ao lado dos dados relacionais que pesquisa, falha de formas que já sei como depurar, e adicionar capacidades vetoriais a um deployment Postgres existente levou menos de um dia.
Comece com a pergunta "o que se encaixa no meu sistema existente?" em vez de "o que tem melhores benchmarks?" Você vai publicar mais rápido e operar com menos fricção.