Vector Database Comparison (Ranked by GitHub Stars) 向量数据库对比(按 GitHub Stars 排序)
The following table ranks 8 major open source vector databases by GitHub stars as of June 2026. All listed databases are open source with self-hosting options; several also offer managed cloud services.
下表按 2026 年 6 月的 GitHub Stars 数对 8 个主流开源向量数据库进行排名,所有列出的数据库均为开源并支持自托管,部分还提供托管云服务。
| # | Database | GitHub Stars | Best For | Cloud / Self-host | License |
|---|---|---|---|---|---|
| 1 | Milvus | 44,567 | Large-scale production with billions of vectors | Both | Apache-2.0 |
| 2 | Faiss | 40,175 | Research and batch similarity search | Self-host only | MIT |
| 3 | Qdrant | 31,717 | High-performance filtering + hybrid search | Both | Apache-2.0 |
| 4 | Chroma | 28,163 | Local development and LangChain integration | Both | Apache-2.0 |
| 5 | pgvector | 21,548 | Adding vector search to existing PostgreSQL | Self-host | PostgreSQL |
| 6 | txtai | 12,622 | All-in-one embeddings + search pipeline | Self-host | Apache-2.0 |
| 7 | Weaviate | 16,258 | Semantic search with built-in ML models | Both | BSD-3 |
| 8 | LanceDB | 10,463 | Serverless, embedded vector DB for apps | Both | Apache-2.0 |
Which Vector Database Should You Choose? 如何选择适合你的向量数据库?
The right vector database depends on your development stage, dataset scale, infrastructure preferences, and query requirements. Here's a scenario-based decision guide.
选择合适的向量数据库取决于你的开发阶段、数据集规模、基础设施偏好和查询需求。以下是基于场景的决策指南。
In 2026, the vector database decision has become clearer: Chroma for prototyping, pgvector if you're Postgres-native, and Qdrant for production RAG at serious scale. Milvus remains the choice when you have genuine billion-vector requirements. The interesting emerging pattern is "hybrid search" — combining dense vector search with sparse BM25 keyword search — which Qdrant and Weaviate handle best. Pure dense vector search alone often underperforms when users include specific named entities or product codes in their queries, which sparse retrieval handles better.
2026 年,向量数据库的选型决策已越来越清晰:原型阶段用 Chroma,Postgres 用户用 pgvector,生产规模 RAG 用 Qdrant。Milvus 是真正需要亿级向量规模时的选择。正在涌现的有趣模式是"混合搜索"——将密集向量搜索与稀疏 BM25 关键词搜索结合——Qdrant 和 Weaviate 在这方面表现最好。单纯的密集向量搜索在用户查询中包含特定命名实体或产品编号时往往表现欠佳,而稀疏检索则能更好处理这类情况。
— AI Nav Editorial Team, June 2026Database Deep Dives 数据库详细解析
Milvus — Enterprise-Grade at Billion-Vector Scale
Milvus is a cloud-native, distributed vector database purpose-built for production scale. Its architecture separates storage, compute, and coordination into independent microservices, enabling horizontal scaling of each component independently. Milvus supports GPU acceleration, multiple index types (FLAT, IVF_FLAT, HNSW, DiskANN), and can handle tens of billions of vectors with sub-millisecond query latency. The managed cloud version is Zilliz Cloud. If you're building a large-scale recommendation system, image similarity search, or enterprise knowledge base, Milvus is the most battle-tested option.
Milvus 是一个云原生分布式向量数据库,专为生产规模而生。其架构将存储、计算和协调分离为独立的微服务,可对每个组件独立进行水平扩展。Milvus 支持 GPU 加速、多种索引类型(FLAT、IVF_FLAT、HNSW、DiskANN),能以毫秒以下的查询延迟处理数百亿向量。托管云版本为 Zilliz Cloud。如果你在构建大规模推荐系统、图像相似性搜索或企业知识库,Milvus 是经过最充分验证的选择。
Qdrant — The Production RAG Champion
Qdrant is written in Rust, which gives it exceptional memory efficiency and query throughput compared to Python or Java-based alternatives. Its standout features are: sparse+dense hybrid search with Reciprocal Rank Fusion (RRF), rich payload metadata filtering evaluated server-side before vector operations, on-disk HNSW indexing for datasets larger than RAM, and a clean REST+gRPC API. Qdrant Cloud offers a generous free tier (1GB) and transparent per-GB pricing. For most developers building production RAG applications in 2026, Qdrant has become the default choice.
Qdrant 使用 Rust 编写,相比 Python 或 Java 的竞品具有卓越的内存效率和查询吞吐量。其突出特性包括:稀疏+密集混合搜索(RRF 融合)、在向量操作前服务端侧评估的丰富元数据过滤、用于超出内存数据集的磁盘 HNSW 索引,以及简洁的 REST+gRPC API。Qdrant Cloud 提供慷慨的免费套餐(1GB)和透明的按 GB 计费。对于 2026 年构建生产 RAG 应用的大多数开发者,Qdrant 已成为默认选择。
Chroma — The Developer-Friendly Starting Point
Chroma optimizes for developer experience above all else. It runs as an in-process Python library (no server needed) or as a lightweight server, persists to disk with a single line of code, and integrates natively with LangChain, LlamaIndex, and most other Python AI frameworks. Chroma handles the embedding model management for you if desired. For local development, RAG prototyping, and applications handling up to a few million vectors, Chroma's simplicity is genuinely unmatched. Chroma Cloud (managed service) launched in 2025 for teams that want production Chroma without self-hosting.
Chroma 最优先考虑开发者体验。它可以作为进程内 Python 库(无需服务器)或轻量级服务器运行,用一行代码持久化到磁盘,并与 LangChain、LlamaIndex 及大多数 Python AI 框架原生集成。如有需要,Chroma 还可以为你管理嵌入模型。对于本地开发、RAG 原型以及处理数百万向量以内的应用,Chroma 的简便性确实无与伦比。Chroma Cloud(托管服务)于 2025 年面向不想自托管的团队推出。
pgvector — SQL Vector Search for Postgres Users
pgvector adds vector similarity search to PostgreSQL as a native extension. It supports L2 distance, inner product, and cosine distance operators, HNSW and IVFFlat indexing methods, and can store vectors alongside regular Postgres columns in the same table. The key advantage is architectural simplicity: you query vectors with SQL, get ACID transactions, use your existing Postgres tooling (backups, replication, ORMs), and don't need to maintain a second database. Major cloud providers (AWS RDS, Supabase, Neon, Google AlloyDB) support pgvector natively. Performance is sufficient for most applications — limitations only appear at very high query volume or extreme scale.
pgvector 以原生扩展的形式为 PostgreSQL 添加向量相似性搜索。支持 L2 距离、内积和余弦距离算子,HNSW 和 IVFFlat 索引方法,可在同一张表中将向量与普通 Postgres 列一起存储。关键优势在于架构简洁性:你用 SQL 查询向量,获得 ACID 事务,使用现有的 Postgres 工具链(备份、复制、ORM),无需维护第二个数据库。主要云服务商(AWS RDS、Supabase、Neon、Google AlloyDB)均原生支持 pgvector。对大多数应用性能已足够——局限性只在极高查询量或极端规模时才会显现。
Quick Start: Build a RAG Pipeline with Chroma + LangChain 快速上手:用 Chroma + LangChain 构建 RAG 流水线
Here's a minimal working RAG pipeline using Chroma as the vector store and LangChain for orchestration:
以下是使用 Chroma 作为向量存储、LangChain 进行编排的最简可用 RAG 流水线:
# 安装依赖
pip install langchain langchain-openai langchain-chroma chromadb
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain_chroma import Chroma
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.chains import RetrievalQA
# 准备文档
documents = [
"Qdrant is a vector database written in Rust, optimized for high-performance filtering.",
"Milvus is a cloud-native distributed vector database for billion-scale deployments.",
"Chroma is designed for developer simplicity and LangChain integration.",
"pgvector adds vector search to PostgreSQL as a native extension.",
]
# 切分文档
splitter = RecursiveCharacterTextSplitter(chunk_size=200, chunk_overlap=20)
chunks = splitter.create_documents(documents)
# 创建向量存储(自动嵌入并存储)
embeddings = OpenAIEmbeddings()
vectorstore = Chroma.from_documents(
documents=chunks,
embedding=embeddings,
persist_directory="./chroma_db" # 持久化到磁盘
)
# 创建 RAG 检索链
retriever = vectorstore.as_retriever(search_kwargs={"k": 3})
llm = ChatOpenAI(model="gpt-4o-mini")
qa_chain = RetrievalQA.from_chain_type(
llm=llm,
retriever=retriever,
return_source_documents=True
)
# 提问
result = qa_chain.invoke("Which vector database is best for high-performance filtering?")
print(result["result"])
To switch from Chroma to Qdrant in production, simply replace the vector store initialization:
在生产环境中从 Chroma 切换到 Qdrant,只需替换向量存储初始化部分:
# 安装 Qdrant 客户端
pip install langchain-qdrant qdrant-client
from langchain_qdrant import Qdrant
from qdrant_client import QdrantClient
# 连接本地 Qdrant(先 docker run -p 6333:6333 qdrant/qdrant)
client = QdrantClient(host="localhost", port=6333)
vectorstore = Qdrant.from_documents(
documents=chunks,
embedding=embeddings,
url="http://localhost:6333",
collection_name="my_rag_docs",
)
# 其余代码完全相同 — LangChain 接口统一
retriever = vectorstore.as_retriever(search_kwargs={"k": 3})
Performance at a Glance 性能速览
This is a high-level comparison based on public benchmarks and community reports. Actual performance varies heavily by dataset size, query complexity, hardware, and configuration.
以下是基于公开基准测试和社区报告的高层对比,实际性能因数据集大小、查询复杂度、硬件和配置不同而差异显著。