Etapa 05 de 22
Bancos de dados vetoriais
Armazenar embeddings e encontrar os mais próximos em milissegundos. Esta é a memória que a sua aplicação consulta a cada pergunta. Custo, filtragem e operação importam mais do que a velocidade bruta.
Por Sheela · Verificado em 23 de out. de 2026 · Como avaliamos
Como escolher
- Já usa Postgres e tem volume modesto: o pgvector mantém um único banco de dados para operar.
- Muita filtragem, busca híbrida ou grande escala: um mecanismo dedicado como Qdrant, Weaviate ou Milvus.
- Nenhum servidor para gerenciar: um serviço hospedado como o Pinecone, com custo mensal.
O que observar
As perguntas que separam as opções, em ordem de importância.
01
Qualidade da busca com filtros
Consultas reais quase sempre são filtradas por permissões, ID do tenant, data ou tipo de documento, e os resultados precisam continuar relevantes depois que o filtro é aplicado. Mecanismos que filtram depois da busca vetorial podem devolver três resultados quando você pediu dez, ou deixar passar sem aviso a melhor correspondência. O Qdrant acrescenta arestas no grafo para campos de payload indexados, para que a navegação filtrada continue conectada; o pgvector precisa de varreduras iterativas (0.8.0 em diante) ou de índices parciais. Teste com o seu filtro real mais seletivo, não com uma demonstração sem filtro.
02
Busca híbrida: vetores mais palavras-chave
Os vetores deixam passar nomes, identificadores e termos exatos, como códigos de produto e mensagens de erro; a busca por palavra-chave (BM25) os pega. A busca híbrida roda as duas e combina as notas. Weaviate, Qdrant, Milvus, LanceDB e turbopuffer fazem isso em um único mecanismo; o Pinecone oferece índices sparse-dense ou um filtro de texto completo; com o pgvector, você mesmo combina a busca de texto completo do Postgres em SQL. Verifique se é possível ajustar os pesos ou usar reciprocal rank fusion.
03
Recall contra latência
A busca aproximada troca precisão por velocidade: o recall é a parcela dos vizinhos mais próximos verdadeiros que ela recupera, e você quer esse recall no tempo de resposta de que precisa, não a qualquer velocidade. O HNSW, um grafo em camadas, oferece recall alto, mas quer o índice na RAM; o IVF agrupa os vetores e busca nos grupos mais próximos; índices em disco (o DiskANN do Milvus, o HFresh do Weaviate, o SPFresh ou SPANN do turbopuffer e do Chroma Cloud) mantêm a maior parte dos dados em SSD ou em armazenamento de objetos. A quantização encolhe os vetores de 4 a 32 vezes, geralmente com uma etapa de repontuação para recuperar a precisão. Sobre benchmarks: o ANN-Benchmarks, mantido pelos acadêmicos Martin Aumueller, Erik Bernhardsson e Alec Faitfull, mostra o recall contra consultas por segundo para consultas isoladas em pequenos datasets públicos; ele compara algoritmos de índice, não bancos de dados, e ignora filtros, escritas e operação. O VectorDBBench é mantido pela Zilliz, a empresa por trás do Milvus, e acrescenta latência p99, casos com filtros e streaming e custo por consulta. Compare QPS e p99 no mesmo recall e trate qualquer benchmark de um fornecedor sobre o próprio produto como uma alegação a reproduzir.
04
Capacidade para a carga de trabalho
Dimensione o trabalho antes de escolher: número esperado de vetores, dimensões, consultas simultâneas e com que frequência os dados mudam. Vetores vezes dimensões vezes bytes dá a memória bruta de que um índice em memória precisa. A Encore, que vende hospedagem de Postgres, coloca o pgvector no mesmo nível do Pinecone abaixo de cerca de cinco milhões de vetores e exigindo ajustes cuidadosos acima disso; o Chroma serve de protótipos a dezenas de milhões; o FAQ do LanceDB diz que a biblioteca open source lida com milhões de vetores em um único nó; o Milvus e o turbopuffer são feitos para bilhões.
05
Atualizações e exclusão
Verifique com que rapidez inserções, edições e exclusões passam a valer na busca. Alguns índices absorvem os dados novos na hora, outros acumulam as escritas ou precisam ser reconstruídos; as escritas do turbopuffer vão para o armazenamento de objetos em 248 ms no p90 para um upsert de 512 KB. A exclusão importa para a conformidade: quando um usuário retira um documento, ele precisa parar de aparecer nos resultados rapidamente, e índices por tenant tornam simples apagar um cliente inteiro.
06
Segurança e isolamento
Procure controle de acesso, criptografia em repouso e em trânsito e um isolamento entre tenants que se sustente. Se as permissões são aplicadas por um filtro de metadados, esse filtro precisa ser confiável em todas as consultas, o que é mais um motivo para testar o recall com filtros. O turbopuffer oferece namespaces ilimitados e chaves gerenciadas pelo cliente no enterprise; o Qdrant pode marcar um campo como chave do tenant; o Weaviate tem multi-tenancy nativo, embora o seu recurso de namespaces agora exija uma licença paga; no pgvector, você particiona por tenant ou usa segurança em nível de linha.
07
Operação
Backups, recuperação, monitoramento e escalabilidade muitas vezes custam mais do que a licença. O pgvector não acrescenta nada novo para operar se você já tem Postgres. O Qdrant vem como um único binário; o Milvus em escala exige Kubernetes e uma equipe de plataforma. O Chroma e o LanceDB rodam dentro do seu processo. O Pinecone e o turbopuffer são apenas gerenciados, com opção de rodar na sua própria nuvem para compradores enterprise. A licença decide a sua saída: Apache 2.0 (Qdrant, Milvus, Chroma, LanceDB) e a licença PostgreSQL (pgvector) permitem hospedar livremente, o Weaviate é open core desde setembro de 2026, e os serviços proprietários significam exportar e reindexar para sair.
08
Custo total
Conte índices, armazenamento de metadados, consultas e atualizações, e se você precisa mesmo de um banco de dados separado. Os serviços gerenciados cobram em unidades diferentes: o Pinecone por unidades de leitura, unidades de escrita e GB armazenados, o Weaviate Cloud por dimensões de vetores armazenadas, o turbopuffer pelo uso acima de um mínimo mensal, o Chroma Cloud pelos dados gravados, armazenados e consultados. Um chatbot com muitas leituras e um pipeline de indexação com muitas escritas podem ordenar os mesmos fornecedores de formas opostas, então simule os seus próprios volumes na calculadora de cada um e compare com uma instância que você mesmo operaria.
Qual abordagem para quais dados
Cada tipo de conteúdo pede modelos diferentes. Muitos sistemas usam mais de um e roteiam pelo tipo de dado.
| Seus dados | Abordagem | Comece com |
|---|---|---|
| Já usa Postgres, com menos de cerca de 10 milhões de vetores | Acrescente vetores ao banco de dados que você já opera; os filtros são SQL e não há nada novo para operar. | pgvector |
| SaaS multi-tenant com permissões por usuário | Escolha uma busca com filtros forte ou um namespace por tenant, e teste o recall com os filtros de permissão. | Qdrant, turbopuffer, Weaviate |
| Muita necessidade de palavras-chave: nomes, códigos, identificadores | Escolha um mecanismo com busca híbrida BM25 e vetorial integrada. | Weaviate, Qdrant, Milvus |
| De centenas de milhões a bilhões de vetores | Use um mecanismo distribuído ou baseado em armazenamento de objetos feito para essa escala. | Milvus, turbopuffer |
| Sem equipe de operação, tráfego imprevisível | Use um serviço totalmente gerenciado e limite os gastos com os limites do plano. | Pinecone, turbopuffer |
| No dispositivo, em notebooks ou agentes locais | Rode uma biblioteca embutida dentro do processo, sem servidor. | Chroma, LanceDB |
| Dados multimodais em um data lake | Mantenha os embeddings ao lado dos arquivos brutos e faça a busca diretamente ali. | LanceDB, Milvus |
Como testar com seus próprios dados
- Monte de 50 a 100 perguntas representativas e marque os trechos corretos de cada uma.
- Inclua casos difíceis: abreviações, IDs e códigos exatos, perguntas ambíguas e documentos com permissão restrita.
- Meça o Recall@k: com que frequência os trechos corretos aparecem entre os k primeiros resultados.
- Meça a qualidade da ordenação, como NDCG@10 ou MRR, para que o trecho certo fique perto do topo, e não apenas presente.
- Meça a latência no p95 com concorrência realista e com os seus filtros reais ativados.
- Some o custo total: indexação, armazenamento, consultas e atualizações no volume esperado.
- Verifique a qualidade da resposta final e avalie o pipeline inteiro (modelo de embedding, banco de dados, reranker e LLM) junto, não só o banco de dados.
Como as opções se diferenciam
Duas escolhas são fáceis de confundir. O modelo de embedding decide o que conta como parecido; o banco de dados vetorial decide com que eficiência você armazena, filtra e recupera esses embeddings. Avalie os dois separadamente e depois teste-os juntos com os seus próprios dados. E antes de acrescentar um sistema novo, verifique o banco de dados que você já opera: se a busca vetorial dele atende às suas necessidades de recuperação e filtragem, talvez você não precise de outro.
Os bancos de dados vetoriais se dividem em cinco famílias. Uma extensão do Postgres (pgvector) coloca os embeddings em uma tabela comum, então os filtros são SQL, os dados ficam nas mesmas transações e backups e não há nada novo para operar; é o padrão para alguns milhões de vetores. Mecanismos dedicados (Qdrant, Weaviate, Milvus) são servidores separados feitos só para busca: lidam com filtragem pesada, busca híbrida por palavra-chave e vetores, quantização e escala maior, ao preço de mais um sistema para operar. O Qdrant é o mais simples de operar, o Weaviate lidera em busca híbrida e embedding integrado, e o Milvus foi projetado para espalhar bilhões de vetores por muitas máquinas.
Bibliotecas embutidas (Chroma, LanceDB) rodam dentro da sua aplicação, como o SQLite, sem servidor: ideais para protótipos, notebooks, apps locais e agentes, mais fracas com muitos usuários simultâneos. Serviços totalmente gerenciados (Pinecone, turbopuffer) eliminam toda a operação e cobram pelo uso; o Pinecone mantém os índices aquecidos, enquanto o turbopuffer mantém os dados em armazenamento de objetos, o que é mais barato em escala enorme, mas mais lento em consultas frias. Mecanismos de busca com suporte a vetores (Elasticsearch, OpenSearch) e bancos de dados de grafos como o Neo4j também armazenam vetores, o que faz sentido se você já os usa para busca por palavra-chave ou para relações, mas eles não são tratados aqui.
8 ferramentas comparadas
Ordenadas pela nossa nota. Abra qualquer avaliação para ver as fontes, os preços e o veredito completo.
| Ferramenta | Nota | Nosso veredito | Ideal para | Preço |
|---|---|---|---|---|
| Qdrantrepositório | 4.7/5 | A busca vetorial filtrada bem-feita torna o Qdrant o banco de código aberto a ser batido para RAG em produção, desde que alguém proteja um servidor que vem aberto. | Equipes que rodam RAG ou busca em produção e precisam de consultas vetoriais filtradas rápidas. | Gratuito e de código aberto sob a licença Apache 2.0. O Qdrant Cloud tem um cluster gratuito de 1 GB e depois cobrança por uso; Premium, Hybrid e Private Cloud têm preço definido pela equipe de vendas. |
| pgvectorrepositório | 4.6/5 | Para a maioria das equipes que já usam Postgres, um banco de dados vetorial dedicado é infraestrutura extra que o pgvector torna desnecessária. | Equipes que já usam Postgres e constroem RAG ou busca semântica sobre alguns milhões de vetores. | Gratuito e de código aberto sob a PostgreSQL License. O único custo é a instância de Postgres que você já roda, ou uma maior. |
| Milvusrepositório | 4.4/5 | Feito para bilhões de vetores e pago em esforço operacional; abaixo de algumas centenas de milhões, é mais banco de dados do que a maioria das equipes precisa. | Equipes de plataforma que rodam busca vetorial com centenas de milhões a bilhões de vetores. | Gratuito e de código aberto sob Apache 2.0. O Zilliz Cloud é o serviço gerenciado: plano gratuito (5 GB, cinco coleções), Dedicated a partir de US$ 63, US$ 16 ou US$ 5 por milhão de vetores de 768 dimensões por mês (performance, capacity ou tiered), Enterprise a partir de US$ 197 por mês, Business Critical sob orçamento. |
| Pineconeferramenta | 4.2/5 | O Pinecone elimina quase todo o trabalho de operação da busca vetorial e cobra por isso a cada leitura, o que serve muito melhor a uma equipe pequena do que a um índice de produção movimentado. | Equipes sem pessoal de operação de banco de dados que querem busca vetorial gerenciada e aceitam tarifas por uso. | Starter gratuito (2 GB, 1M unidades de leitura/mês, só AWS us-east-1). Builder US$ 20/mês fixo, com cotas rígidas. Standard com mínimo de US$ 50/mês, depois US$ 0,33/GB/mês de armazenamento, US$ 16–US$ 18 por 1M unidades de leitura, US$ 4–US$ 4,50 por 1M unidades de gravação. Enterprise com mínimo de US$ 500/mês. |
| Weaviaterepositório | 4.2/5 | A busca híbrida de palavra-chave e vetor continua sendo o melhor argumento do Weaviate, mas seus recursos operacionais mais novos agora dependem de uma chave de licença. | Equipes criando busca ou RAG onde palavras-chave exatas e similaridade semântica são igualmente importantes. | O Core é BSD-3-Clause; alguns recursos corporativos exigem uma chave de licença paga. Weaviate Cloud: Free (100.000 objetos), Flex pay-as-you-go com mínimo de $45/mês, Premium a partir de $400/mês em contrato pré-pago. |
| turbopufferferramenta | 4.2/5 | O turbopuffer é o banco de dados vetorial a ser batido se o seu produto tem milhões de índices separados e quase sempre ociosos, desde que você aceite que a primeira busca em um índice frio leve cerca de um segundo. | Equipes que constroem produtos de IA multi-tenant com muitos índices separados ou bilhões de vetores e não querem operar servidores. | Launch: uso mínimo de $16/mês; Scale: mínimo de $256/mês (SSO, HIPAA BAA); Enterprise a partir de $4.096/mês com acréscimo de 35% sobre o uso (BYOC, single-tenant, SLA de 99.95%). Armazenamento até $0.33/GB, gravações até $2/GB, consultas até $1/PB consultado. Sem nível gratuito. |
| Chromarepositório | 4.1/5 | Rápido de embutir e barato de hospedar para RAG com muita leitura, embora nada tenha recebido tag desde maio de 2026. | Desenvolvedores prototipando RAG ou rodando busca vetorial de porte pequeno a médio. | Gratuito e de código aberto sob Apache 2.0. Chroma Cloud: Starter a $0 mais uso, com $5 em créditos; Team a $250/mês mais uso; Enterprise sob medida. Gravações a $2.50/GiB, armazenamento a $0.33/GiB-mês. |
| LanceDBrepositório | 4.0/5 | Quando seus embeddings ficam ao lado de imagens, vídeo ou dados de treinamento, o LanceDB elimina por completo o banco de dados separado, embora busca intensa com muitos usuários não seja o propósito da biblioteca gratuita. | Equipes que trabalham com dados multimodais ou de treinamento e querem busca vetorial sem rodar um servidor. | Gratuito e de código aberto sob Apache 2.0. O LanceDB Enterprise é vendido com compromissos anuais; o AWS Marketplace lista um compromisso de 12 meses por $60,000, com ofertas privadas sob consulta. |
Lado a lado
As especificações que importam nesta etapa. Verificadas em 23 de out. de 2026; confirme no site do fornecedor antes de decidir.
| Ferramenta | Tipo | Licença | Tipos de índice | Busca híbrida | Opções de hospedagem | Escala ideal |
|---|---|---|---|---|---|---|
| Qdrant | Mecanismo dedicado (Rust) | Apache 2.0 | HNSW, sparse inverted; TurboQuant/BQ/PQ | Sim, sparse + dense em uma consulta | Self-hosted, Qdrant Cloud, Edge | De milhões a centenas de milhões |
| pgvector | Extensão do Postgres | Licença PostgreSQL | HNSW, IVFFlat; half, binary, sparse | Via texto completo do Postgres em SQL | Qualquer Postgres, a maioria dos serviços gerenciados | Alguns milhões de vetores (cerca de 5M segundo a Encore) |
| Milvus | Mecanismo distribuído (Go/C++) | Apache 2.0 | HNSW, IVF, DiskANN, SCANN, flat | Sim, BM25 + sparse + dense | Self-hosted (Kubernetes), Zilliz Cloud | De centenas de milhões a bilhões |
| Pinecone | Serviço totalmente gerenciado | Proprietária | Não publicado | Sparse-dense ou filtro de texto completo | Serverless; BYOC no Enterprise | Qualquer uma; o custo cresce com as leituras |
| Weaviate | Mecanismo dedicado (Go) | Núcleo BSD-3 + recursos comerciais | HNSW, flat, dynamic, HFresh | Sim, BM25 + vetores, ajustável | Self-hosted, Weaviate Cloud | Não publicado |
| turbopuffer | Gerenciado, baseado em armazenamento de objetos | Proprietária | SPFresh + quantização binária RaBitQ | Sim, BM25 + vetores | Multi-tenant, single-tenant, BYOC | Bilhões de vetores, muitos tenants |
| Chroma | Biblioteca embutida ou servidor | Apache 2.0 | HNSW (nó único), SPANN (Cloud) | Texto completo junto com vetores | No processo, servidor, Chroma Cloud | De protótipos a dezenas de milhões |
| LanceDB | Biblioteca embutida (arquivos Lance) | Apache 2.0 | IVF (PQ/SQ/RQ), IVF_HNSW | Texto completo BM25 + vetores | No processo, em disco ou S3; Enterprise | Apps locais; milhões de vetores por nó |
Conecte ao seu agente
Servidores MCP que permitem que assistentes como Claude, ChatGPT e Cursor usem essas ferramentas diretamente.
Onde esta etapa se encaixa
- Converse com os seus documentos: começaríamos com Qdrant.
- Agente de atendimento ao cliente: começaríamos com pgvector.
- Agente de programação: começaríamos com LanceDB.
- Pesquisa e grafo de conhecimento: começaríamos com Weaviate.
- Assistente com memória de longo prazo: começaríamos com Qdrant.
- Pipeline de geração de imagens: começaríamos com Qdrant.
- Produção de vídeo: começaríamos com LanceDB.
- Agente de voz: começaríamos com pgvector.
- IA privada no dispositivo: começaríamos com LanceDB, Chroma.
Fontes deste guia
- ANN-Benchmarks
- VectorDBBench (Zilliz) no GitHub
- Ranking do VectorDBBench
- Documentação do Qdrant: indexação
- Documentação do Qdrant: quantização
- Documentação do Weaviate: índices vetoriais
- Documentação do Milvus: tipos de índice
- Documentação do Milvus: DiskANN
- Documentação do Chroma: configuração de coleções
- Documentação do Chroma: arquitetura
- Documentação do LanceDB: indexação
- Documentação do Pinecone: busca híbrida
- README do pgvector
- turbopuffer: ANN v3
- FAQ do LanceDB OSS
- pgvector vs Pinecone (Encore)