Benchmark de bancos de dados vetoriais: 7 mecanismos de código aberto para RAG

Avaliamos sete bancos de dados vetoriais de código aberto e auto-hospedados como a camada de recuperação de um pipeline de RAG, cada um executado isoladamente com os mesmos embeddings bge-m3 e consultas médicas e técnicas reais, de modo que o índice do banco de dados fosse a única variável. A carga de trabalho abrangeu os corpora MedRAG-50k, TechQA-28k e um corpus de 2.25M vetores em oito dimensões, desde precisão e qualidade de recuperação até velocidade, memória, busca filtrada e híbrida, custo de construção e churn ao vivo.

Velocidade em thread única

Cada mecanismo é avaliado no mesmo nível de recall, o ponto de operação compartilhado em que seu parâmetro de busca (seja ef ou nprobe) é ajustado até atingir um Recall@10 de 0.95, permitindo uma comparação justa dos números de velocidade.

Em uma única thread de cliente, o Redis atende 764 QPS no MedRAG-50k com pico de 559 MB de RAM, a maior vazão e a menor memória do conjunto. A ordem em thread única é Redis 764, Qdrant 377, Milvus 342, Weaviate 341, pgvector 257, Chroma 197, LanceDB 70, uma diferença de 10x do topo à base. O LanceDB é o ponto fora da curva baseado em disco, trocando RAM por latência com p95 perto de 22 ms. O Redis permanece o mais rápido e o LanceDB o mais lento no TechQA-28k (651 a 81) e em 2.25M (495 a 28), embora o meio se reorganize em escala, onde o Milvus cai do terceiro para o sexto lugar.

Para RAG, a latência de cauda afeta a experiência do usuário mais do que a vazão bruta. A latência por consulta, agregada em 100 execuções de 154 consultas com recall correspondente, acompanha a ordem de vazão.

O Redis foi executado com persistência desativada (sem snapshot RDB nem arquivo somente de acréscimo), portanto seus números de velocidade e memória são para uma configuração volátil, sem durabilidade.

Vazão sob concorrência

O QPS em thread única responde quão rápida é uma consulta. A questão em produção é a vazão sob muitos clientes concorrentes, e a resposta depende de como o cliente é construído, não apenas do banco de dados.

Um cliente de ciclo fechado pode ser acionado de duas maneiras, ambas comuns em aplicações Python de RAG. Um processo assíncrono ou com threads desserializa cada resultado concorrente (gRPC/protobuf ou RESP) em uma única GIL, de modo que o cliente, não o servidor, limita a vazão. Muitos processos worker (o padrão gunicorn -w N) obtêm, cada um, sua própria GIL, expondo muito mais a capacidade do servidor. Medimos ambos em uma máquina de 32 vCPUs com ef=128 fixo e verificamos o recall em todos os pontos.

À medida que a concorrência de requisições sobe de 1 para 512 em até 32 processos worker, as curvas de vazão se cruzam. O Redis começa mais alto com uma requisição e termina mais baixo, enquanto o Weaviate sobe do fim do grupo para um platô de 8330 QPS com 512 requisições, passando por 7.114 no caminho em 32. Em um único processo assíncrono, a classificação acompanha a eficiência de parsing do cliente Python, já que o RESP do Redis é o mais leve de desserializar e perde menos para a GIL.

O pico de processo único e o pico de 32 processos de cada mecanismo são os tetos em toda a varredura de 1 a 512, não a vazão em um número específico de requisições.

O Redis mantém a menor latência de consulta única do conjunto (cerca de 1.6 ms), e seu núcleo de busca single-thread satura em torno de 1642 QPS a 32 requisições concorrentes, e depois anti-escala além disso (o pool de threads de consulta do RediSearch, WORKERS, vem desativado por padrão). O Weaviate e o Milvus (servidores multi-threaded) e o pgvector (um backend Postgres independente por conexão) escalam pelos 32 núcleos. O pgvector tem o menor pico de processo único (536) e o segundo maior pico de 32 processos (4832). Sob um orçamento de p99 abaixo de 100ms, a ordem multi-processo é Weaviate 8290, pgvector 4832, Milvus 4725, Qdrant 1737, Redis 1642.

O parsing gRPC mais pesado do Qdrant torna seu número co-localizado limitado pelo cliente, e não pelo servidor, já que apenas a contagem de processos o move de 455 QPS em um processo para 1859 em 32. Chroma e LanceDB ficaram fora da execução multiprocesso. O Chroma fixa o ef na criação da coleção e anti-escala, com p99 de 13 segundos em 512 requisições, e o LanceDB é embutido, portanto o cenário de cliente de rede não se aplica.

Pegada de memória

Com 50k vetores, o pico de RAM varia de 559 MB (Redis, em RAM, persistência desativada) a 3.300 MB (Milvus), com Weaviate em 1.201, LanceDB em 1.574, Chroma em 1.800 e pgvector em 2.024. A classificação muda em 2.25M, onde o trade-off entre memória e disco se amplia.

O pico de RAM em 2.25M, nos cinco mecanismos em memória, varia de 17.0 GB (Milvus) a 62.4 GB (Chroma), uma faixa de 3.7x, ou 7.5 GB a 27.7 GB por milhão de vetores. O Milvus permanece o mais enxuto porque descarrega o índice para o disco (estilo DiskANN), enquanto os mecanismos HNSW totalmente em RAM crescem mais rápido; assim, o Milvus, o mais pesado em 50k (3.300 MB), é o mais enxuto em 2.25M (17.0 GB), com o Chroma o mais pesado, com 62.4 GB.

Os dois mecanismos em disco ficam fora dessa comparação de RAM porque sua pegada está em disco, e não em RAM. O pgvector mantém um índice em disco de 18.4 GB e o LanceDB um de 12.0 GB em 2.25M, e a RAM de serviço deles é um cache de páginas sobre esse índice, e não o conjunto de trabalho completo, que não foi medido. Uma ressalva também se aplica aos números em memória. Eles são uma marca de pico de construção e serviço, não uma pegada apenas de serviço, portanto uma nova medição somente em serviço é um refinamento em aberto.

Atualidade, escritas e exclusões sob churn ao vivo

As outras sete dimensões medem um corpus com carga estática em lote seguida de leitura. Bases de conhecimento RAG reais adicionam, atualizam e excluem documentos continuamente enquanto o índice é mesclado em segundo plano. Essa carga de churn foi executada no MedRAG-50k em uma máquina separada de 8 vCPUs, portanto sua vazão é interna a esta seção e não é comparável aos números de velocidade de 32 núcleos. Os sinais de correção (verificações de recall e tombstone) são independentes de hardware.

Atualidade (leitura após gravação). Na configuração de consistência com que cada mecanismo foi configurado, todos são de leitura após gravação. Um documento recém-gravado é pesquisável imediatamente, com zero de cerca de 150 gravações não visíveis. A latência entre confirmação de gravação e visibilidade na busca é de 2 ms p50 para Redis, 4 ms para Weaviate, 9 ms para Qdrant, 12 ms para Milvus, 14 ms para pgvector, 31 ms para LanceDB e 41 ms para Chroma. O Milvus encontra a nova linha por meio de uma varredura de consistência forte do segmento em crescimento ainda não selado (o vetor entra no grafo HNSW persistente mais tarde), portanto seus 12 ms são a pesquisabilidade do segmento em crescimento, uma leitura após gravação válida do ponto de vista do usuário.

Escritas e leituras sob carga mista. Com um gravador visando 150 escritas/s e seis leitores consultando por 60 segundos, o recall de leitura se manteve entre 0.96 e 1.00 em todos os mecanismos, e nenhum índice se degradou sob gravações concorrentes. A vazão de gravação de linha única separa os mecanismos em 57x, e a ordem é próxima do inverso da classificação de construção estática.

O LanceDB paga um commit de cópia em gravação por linha, e o Chroma uma adição via HTTP por linha, razão pela qual os construtores estáticos mais rápidos são os mais lentos sob churn. A vazão de gravação aqui é a taxa alcançada contra uma meta de 150/s sob leituras concorrentes, de modo que os mecanismos rápidos são limitados perto de 150 em vez de mostrar seu pico. Interprete isso como comportamento de gravação online de linha única e alta frequência, não ingestão em lote, que é o ponto de projeto desses mecanismos e não foi testado aqui.

Exclusão e compactação. Ao excluir 20% aleatórios do conjunto ativo e reinserir 20% de documentos novos, o vazamento de tombstones foi zero em todos os mecanismos. Uma id excluída nunca reapareceu na busca, e o Recall@10 permaneceu entre 0.97 e 1.00 após o ciclo completo. A correção se mantém sob churn em todos os lugares. O custo difere por mecanismo. O pgvector paga um VACUUM de 53 segundos e o Milvus uma compactação de 11 segundos, enquanto a reinserção dos mecanismos de gravação lenta domina (Chroma 276 s, LanceDB 1139 s para cerca de 6.000 documentos).

O Weaviate executou esta seção com 3.000 documentos iniciais em vez de 30.000 (sua ingestão em lote síncrona é lenta na máquina pequena), portanto seu QPS de leitura está em um corpus menor. Nessa escala, sua atualidade corrigida é de cerca de 5 ms e sua taxa de gravação, cerca de 102/s, o que coloca ambos no meio do grupo.

Métricas explicadas

ANN Recall@10 é a fração dos 10 vetores vizinhos verdadeiros mais próximos (segundo um oráculo kNN exato de força bruta sobre os mesmos embeddings indexados pelo banco) que o índice aproximado retornou. Isso isola o banco de dados (tipo de índice, ef/nprobe, implementação), não o embedding.

nDCG@10 é uma pontuação de 0 a 1 ponderada pela posição que indica se o documento correto rotulado por humanos aparece perto do topo da lista de resultados. Ela mede a relevância da recuperação de ponta a ponta, que é em grande parte uma propriedade do model de embedding, mantida constante aqui em todos os mecanismos.

Δ (ponte delta) é o nDCG@10 do oráculo menos o nDCG@10 do banco de dados em uma determinada configuração de busca. Ele converte o erro de aproximação de cada mecanismo na qualidade de resposta que sua velocidade custa, reportável porque temos tanto um oráculo quanto rótulos humanos.

Constatações do benchmark de bancos de dados vetoriais

Os sete mecanismos empatam na precisão de recuperação

Com Recall@10 = 0.95 no MedRAG-50k, o nDCG@10 fica entre 0.803 (pgvector) e 0.817 (LanceDB), uma diferença de 0.014. A ponte delta-oráculo varia de 0.009 (LanceDB) a 0.023 (pgvector), portanto a aproximação do banco de dados custa no máximo 0.023 pontos de nDCG de qualidade de resposta.

Sob este embedding, corpus, k=10 e ponto de operação de 0.95, a escolha do banco de dados altera o nDCG@10 em no máximo 0.014, contra a diferença de 10x na vazão em thread única e a diferença de 3.7x no pico de memória mostradas acima. A escolha do índice começa a afetar a qualidade em Recall@10 = 0.99 ou acima, em k maior, em corpora muito maiores ou com índices quantizados.

A confiabilidade da recuperação varia mais pelo que a consulta pergunta do que pelo banco de dados que a responde. Nas 154 consultas MedRAG no oráculo kNN exato, buscas factuais pontuam 0.888 nDCG@10, perguntas condicionais 0.836, comparativas 0.779 e de existência de cláusula 0.763. A lacuna de 0.125 entre factual e existência de cláusula está presente de forma idêntica em todos os sete mecanismos.

Filtros de metadados custam vazão, não recall

Com um predicado de metadados aplicado, o Recall@10 de pior caso permanece entre 0.968 (Redis) e 1.00 (Weaviate, pgvector, LanceDB) em uma grade de seletividade (1/5/20/50%) e correlação de predicado (dispersa e agrupada). A separação está na vazão filtrada.

A separação é a vazão. Chroma (11-19 QPS) e pgvector (10-56 QPS) mantêm o recall com vazão filtrada 20 a 40x menor que os demais. O Milvus mantém o maior recall de pior caso (0.984) com 268 a 732 QPS ao longo da seletividade, enquanto o Redis é mais rápido em baixa seletividade (1.374 QPS em 1%) com um piso de recall menor (0.968). Em seletividade de 1-5%, um recall de 1.00 é em grande parte o ramo de varredura completa exata do planejador de consultas abaixo do limiar de varredura completa de cada mecanismo, não HNSW filtrável, conforme divulgado por mecanismo.

*O recall filtrado do LanceDB foi medido inicialmente em 0.24 em filtros agrupados e depois retratado. A varredura variou ef, mas o controle de recall do LanceDB é nprobes, então ele rodou em um padrão de cerca de 9% das partições. Medido novamente com nprobes adequados, o Recall@10 agrupado se recupera de 0.24 para 0.76 (nprobes=128) e para cerca de 1.00 (nprobes=256), com QPS 3 a 5x menor. O LanceDB mantém o recall filtrado, lentamente. Uma medição de vazão filtrada com recall correspondente e no mesmo host ainda está pendente, portanto o QPS filtrado do LanceDB não é listado.

A busca híbrida adiciona até 0.067 nDCG

Adicionar um braço de palavras-chave BM25 padrão e fundi-lo com o braço denso por meio de fusion de classificação recíproca (RRF, k=60) eleva o nDCG@10 em 0.030 a 0.067 para todos os mecanismos com braço de palavras-chave. No MedRAG, os braços denso e BM25 têm força individual quase igual (cerca de 0.80 cada), portanto o ganho recupera os erros de cada braço, em vez de um braço dominar.

Os mecanismos com um braço BM25 forte ganham mais, e pgvector e Weaviate ganham menos, acompanhando seus braços de palavras-chave mais fracos (0.740 e 0.782). Nenhum híbrido de mecanismo fica abaixo de seu braço denso quando medido corretamente.

O que separa os mecanismos é a fusion nativa versus round-trips no lado do cliente, de Milvus a 340 QPS nativos até pgvector a 12 QPS no cliente. Quatro mecanismos fazem fusion nativamente (Qdrant, Milvus, Weaviate, LanceDB). O Redis executa BM25 e KNN nativos, mas sem fusion no servidor nesta versão, então o cliente faz dois round trips e funde em Python. O pgvector não tem fusion API, funde no cliente, e seu braço de palavras-chave é o Postgres ts_rank (frequência de termo com normalização de comprimento, sem IDF), que com uma varredura de texto completo OR roda a 12 QPS. O Chroma auto-hospedado não tem busca por palavras-chave ranqueada (o BM25 é um recurso do Chroma Cloud), portanto não tem linha de híbrido.

O tempo de construção do índice varia 13x

Com 50k vetores, construir o índice leva de 7 segundos (LanceDB) e 11 a 13 (Weaviate, Milvus) até 88 segundos (pgvector). Em 2.25M, a diferença chega a 13x. LanceDB e Milvus terminam em 7 a 8 minutos, contra 44 minutos para Redis e 92 para pgvector. Normalizado pela taxa da máquina, o custo de construção varia de €0.04 por 1M de vetores (LanceDB) e €0.05 (Milvus) até €0.58 (pgvector). A construção é um custo único, pago novamente apenas quando o corpus é reindexado.

Qualidade de recuperação com 2.25M vetores

Para testar a qualidade em escala mantendo rótulos humanos reais, construímos um corpus de 2.25M vetores. Ele combina os 50k documentos rotulados do MedRAG com 2.2M distratores do PubMed, todos no mesmo espaço bge-m3, com verificação de integridade para que nenhum distrator seja um alvo rotulado incorretamente. Os datasets ANN padrão em escala de bilhões não possuem rótulos humanos de relevância, portanto não mostram o que acontece em seguida.

O recall ANN geométrico se mantém em escala. Todos os mecanismos ainda atingem Recall@10 acima de 0.973 em 2.25M (Qdrant e Milvus em 0.999), portanto o índice encontra os vetores vizinhos verdadeiros mais próximos. A qualidade semântica das respostas não se mantém. O nDCG@10 cai de cerca de 0.81 em 50k para cerca de 0.56 em 2.25M para todos os mecanismos, porque o documento correto fica enterrado entre 2.2M distratores.

O colapso não é um efeito do banco de dados. Ele atinge o oráculo kNN exato de forma idêntica (o nDCG@10 do oráculo em 2.25M é 0.572, e todos os mecanismos ficam nesse teto, em torno de 0.55 a 0.57). Se a causa é o teto do embedding, a ambiguidade do corpus ou os rótulos de positivo único que não captam quase-duplicatas agora relevantes, isso não é decidido aqui. Separar essas causas exige re-rotulação humana dos documentos recém-classificados no topo. O fato reportável é que escalar o corpus 45x apagou cerca de um terço da qualidade das respostas (nDCG@10 de 0.81 para 0.56) enquanto todos os índices ANN relataram recall quase perfeito, um efeito que um benchmark exclusivamente geométrico não detectaria.

Durabilidade, HA e segurança por mecanismo

Velocidade, memória e recall são os eixos medidos. Para uma implantação de RAG em produção, os eixos não medidos (durabilidade, alta disponibilidade, controle de acesso) também diferenciam esses mecanismos. Este inventário de capacidades é fundamentado na documentação oficial de cada mecanismo na edição de código aberto avaliada. É um inventário de capacidades, não um teste de caos. Tempo real de failover, janela de perda de dados na recuperação de falhas e isolamento de inquilinos sob carga não são medidos aqui.

Entre os sete, apenas o pgvector oferece recuperação point-in-time (por meio do arquivamento de WAL do Postgres) e segurança em nível de linha. Qdrant, Milvus e Weaviate incluem replicação e RBAC em suas versões de código aberto, com a ressalva de que a alta disponibilidade do Milvus está no modo distribuído mais pesado, não na versão standalone avaliada aqui. Nenhum dos sete criptografa dados em disco nativamente. Todos dependem de criptografia de disco ou volume na camada de infraestrutura.

Para RAG multilocatário, onde um filtro também serve como limite de controle de acesso, Qdrant, Milvus, Weaviate e pgvector podem impor isolamento de inquilinos dentro do banco de dados. Chroma e LanceDB embutido empurram isso para a aplicação. Um pré-filtro correto retorna menos resultados, um risco de completude, em vez de vazar documentos de outro inquilino. Um vazamento entre inquilinos exigiria um pós-filtro com bug, que nenhum desses mecanismos usou.

Como funciona a busca aproximada de vizinhos mais próximos

Um banco de dados vetorial armazena um vetor de alta dimensão por documento e, dado um vetor de consulta, retorna os k mais próximos por uma métrica de distância (aqui, cosseno sobre vetores normalizados L2). A busca exata de vizinhos mais próximos compara a consulta com todos os vetores armazenados, o que é correto, mas escala linearmente com o tamanho do corpus. Com 50k vetores, isso é rápido. Em milhões, é lento demais para servir.

Índices aproximados de vizinhos mais próximos (ANN) abrem mão de parte da precisão para pesquisar uma fração dos vetores armazenados. A estrutura dominante nesses mecanismos é HNSW, um grafo de proximidade em camadas que caminha de um ponto de entrada grosseiro até uma vizinhança densa, visitando um número limitado de candidatos definido por um controle de busca (ef para HNSW, nprobe para IVF). Um ef maior visita mais candidatos, aumentando o recall e reduzindo o QPS. Um ef menor faz o inverso.

Como esse controle troca recall por velocidade continuamente, comparar dois mecanismos em uma configuração fixa é enganoso, pois um pode estar gastando mais precisão para obter sua velocidade. A comparação justa varre o controle, traça a curva de recall versus QPS de cada mecanismo e lê todos no mesmo recall. Esse ponto de recall correspondente (Recall@10 = 0.95 aqui) é onde os números de QPS, latência e memória deste benchmark são obtidos.

Não perca os nossos benchmarks e insights baseados em dados. O botão abre o Google; selecionar a AIMultiple confirma que deseja ver a AIMultiple com mais frequência nos resultados de pesquisa do Google.

Adicionar como fonte preferencial

Metodologia do benchmark

Mecanismos. Qdrant v1.18.1, Milvus v2.6.0, Weaviate 1.38.0, pgvector 0.8.x (Postgres 17), Chroma 1.5.0, Redis/RediSearch 8.2 e LanceDB 0.34.0, em imagens Docker fixadas. O Redis rodou com persistência desativada (sem snapshot RDB nem arquivo somente de acréscimo).

Hardware. Um Hetzner CCX53 (32 vCPUs dedicadas, 128 GB de RAM, NVMe, nbg1) para precisão, velocidade, memória, busca filtrada e construção, um contêiner ativo por vez, um contêiner novo a cada construção de índice e um cliente single-thread co-localizado. A dimensão de churn ao vivo foi executada em um CCX33 (8 vCPUs, 32 GB).

Embedding. bge-m3, 1024 dimensões, cosseno em float32 normalizado L2, k=10, seed 42, byte-idêntico entre os mecanismos. As consultas carregam rótulos humanos de positivo único (target_doc_id).

Corpora. MedRAG-50k (154 consultas) e TechQA-28k (151 consultas) para qualidade de recuperação, e um corpus de 2.25M vetores (50k rotulados mais 2.2M distratores) para a camada de escala. A dimensão híbrida foi reexecutada em Docker local, portanto seu QPS é comparável entre as linhas híbridas, não aos números da máquina. Seu nDCG e Δ são independentes de hardware.

Estatísticas. 100 ou mais execuções por medição, corte de outliers IQR em 3.0x, cronometragem perf_counter_ns. Pools de consultas de 154 a 246 limitam o relatório de cauda em p95, ocasionalmente p99. p99.9 é indefinido nessas contagens.

Dupla verdade fundamental. Um banco de dados vetorial tem duas verdades fundamentais independentes, e este benchmark pontua ambas. A verdade fundamental geométrica (ANN Recall@10 contra o oráculo exato de força bruta sobre os mesmos vetores) pergunta se o índice retornou os verdadeiros vizinhos mais próximos, isolando o banco de dados. A verdade fundamental semântica (nDCG@10, MRR, Hit@k contra rótulos humanos) pergunta se os documentos retornados são relevantes, o que é em grande parte propriedade do embedding, mantido constante. Como o embedding é congelado, classificar mecanismos por pontuações semânticas brutas classificaria o embedding. O poder do banco de dados aparece como velocidade e memória em recall ANN correspondente, e a ponte Δ traduz sua perda de aproximação em qualidade de resposta.

Âncora de correção. Cada receita por mecanismo (filtrada e híbrida) foi extraída documentação oficial na versão exata e verificada de forma adversarial antes da codificação. A dimensão híbrida carrega uma chave de resposta BM25 independente (duas referências concordam em nDCG em cerca de 0.81), de modo que qualquer mecanismo que pontue longe disso sinaliza um bug no harness, não uma descoberta. Essa proteção sinalizou três erros de medição de primeira passagem, todos em nosso harness (um artefato de temporização de índice assíncrono no Weaviate, uma função de ranqueamento errada do Postgres e um bug de SQL fusion que fez o HNSW ignorar sua configuração ef), que corrigimos medindo novamente todos os sete mecanismos em um ambiente consistente, onde os cinco mecanismos já corretos reproduziram exatamente seus números. As dimensões de concorrência e churn carregam a mesma âncora (reverificações de recall e tombstone), portanto nenhum número relatado é rápido, mas errado.

Significância estatística

Cada número relatado é uma estimativa pontual de bootstrap em 100 ou mais execuções, com intervalo de confiança de 95% a partir de 1.000 reamostragens, e uma diferença é considerada real quando os dois intervalos não se sobrepõem.

O ganho híbrido é o caso-limite, portanto seus intervalos são a evidência decisiva. Quatro mecanismos ficam acima de zero e dois não:

A precisão de recuperação é a mesma regra lida ao contrário. O nDCG@10 dos sete mecanismos fica dentro de intervalos sobrepostos em uma diferença de 0.014, então nenhum vence, o que é o significado do empate. As ordens de velocidade e memória ficam muito fora dessa incerteza, com lacunas (10x de vazão em thread única, 3.7x de pico de memória) que tornam o ruído de bootstrap insignificante.

Mecanismos testados

Limitações

O Redis rodou com persistência desativada, portanto uma configuração de AOF fsync mudaria sua latência de gravação e pegada em relação aos números voláteis relatados aqui.

Os rótulos humanos são de positivo único (um documento correto por consulta), sem relevância graduada ou concordância entre anotadores, portanto nDCG@10, MRR@10 e Hit@10 carregam sinal quase idêntico nesses dados. O embedding é mantido constante por design. Famílias de embedding, dimensões e comportamento multilíngue são um benchmark separado. Esta execução isola a camada de recuperação. O reranker (cross-encoder) e os estágios de geração de respostas com LLM de um pipeline de RAG estão fora do escopo. Mecanismos gerenciados na nuvem (Pinecone, Zilliz e outros) são uma fase posterior. A comparação de durabilidade e segurança é fundamentada em documentação, não testada por caos.

Leitura adicional

• Benchmark de embedding models
• Benchmark de reranker
• Calculadora de banco de dados vetorial
• Embedding models de código aberto
• Embedding models multilíngues
• Embeddings multimodais
• Frameworks de RAG agênticos

Cite este benchmark

Escolha o formato adequado ao local onde você vai publicar. Colar a versão com link no seu CMS preserva o backlink.

@misc{sari2026,
  author = {Sarı, Ekrem},
  title  = {{Benchmark de bancos de dados vetoriais: 7 mecanismos de código aberto para RAG}},
  year   = {2026},
  month  = jul,
  howpublished    = {\url{https://aimultiple.com/open-source-vector-databases}},
  note   = {AIMultiple. Acessado em 17 julho 2026}
}

Registro de alterações

3 atualizações

20262025

1. 17 jul

   Faiss substituído por LanceDB na lista de bancos de dados vetoriais comparados.

2. 27 fev

   Adicionadas atualizações recentes ao Milvus, Qdrant e Chroma.

Ekrem Sarı

Pesquisador de IA

Siga-nos

Ekrem é Pesquisador de IA e Cientista de Dados na AIMultiple. Ele projeta e executa benchmarks práticos para sistemas de IA e LLM.

Ver perfil completo

Seja o primeiro a comentar

Seu endereço de e-mail não será publicado. Todos os campos são obrigatórios. Os comentários são deixados em seu idioma original.

Nome

Endereço de email

Comentário

0/450

Postar comentário