Chroma

选型先看规模，别先看流行度 向量库这两年铺天盖地，但绝大多数团队的真实数据量撑死在几十万到几百万条 chunk——这个量级，杀鸡用牛刀的代价是运维复杂度暴涨。Milvus 这类分布式系统要部署 etcd、MinIO、集群节点，一个人维护都吃力；而你的检索延迟可能只需要 50ms 以内，单机方案完全够。选型第一问永远是：我的向量条数大概多少？QPS 多少？要不要过滤？ 四类方案对号入座 方案 适合规模 优点 代价 Chroma 十万级内、原型验证 pip install 即用，纯嵌入式 不适合高并发生产 pgvector 百万级、已有 PostgreSQL 复用现有库，SQL 联合查询 百万以上 HNSW 调参吃紧 Qdrant 百万到千万、生产混合检索 原生过滤、稀疏向量、Rust 性能 多一个独立服务要运维 Milvus 亿级、大规模分布式 水平扩展成熟 部署重，组件多 一个常被忽略的点：pgvector 的隐性优势是和业务表同库。你的 chunk 带着文档 ID、权限、来源元数据，用 SQL JOIN 直接过滤（比如「只检索当前部门有权看的文档」），比在向量库里单独维护一套 ACL 简单一个数量级。中小团队如果本来就用 PostgreSQL，加个 pgvector 扩展往往是最优解，CREATE EXTENSION vector; 一行搞定。 三个踩坑提醒 第一，HNSW 参数别用默认：ef_construct 和 ef_search 直接决定召回率和延迟的 trade-off，Qdrant、pgvector 都要根据数据量实测，默认值往往偏保守。第二，维度别盲目追高：OpenAI text-embedding-3-small 是 1536 维，bge-m3 是 1024 维，维度越高索引越大、检索越慢，够用就行。第三，量化压缩：Qdrant 支持 scalar 量化和 HNSW on-disk，百万级以上不开量化，内存直接爆——这是很多人「数据一多就 OOM」的根因。 ...

引言 向量数据库是RAG系统的核心基础设施。2026年，随着嵌入维度的增加（从768维到3072维）和数据规模的扩大（从百万到十亿级），向量数据库的性能变得至关重要。本文将全面对比主流向量数据库。 参评数据库 数据库 类型 部署方式 特点 Milvus 2.5 专用 分布式 最强大，可扩展 Qdrant 1.10 专用 单机/分布式 性能优秀，Rust编写 Chroma 0.6 轻量 嵌入式 开发友好，轻量 Weaviate 1.25 专用 分布式 GraphQL API pgvector 0.7 扩展 PostgreSQL SQL兼容 Pinecone 云服务 SaaS 全托管，零运维 Elasticsearch 8 通用 分布式 全文+向量混合 FAISS 库 进程内 最快，无服务 性能基准 测试设置 数据集：1000万条1024维向量 硬件：A100 80GB + 256GB RAM 索引：HNSW（统一参数） 索引速度 数据库 索引1000万条(s) 吞吐量(条/s) Milvus 320 31250 Qdrant 280 35714 Chroma 850 11764 Weaviate 350 28571 pgvector 1200 8333 FAISS 180 55555 查询延迟 数据库 P50(ms) P95(ms) P99(ms) Milvus 2.1 5.5 8.2 Qdrant 1.8 4.2 6.5 Chroma 8.5 15.2 22.0 Weaviate 3.2 7.8 12.1 pgvector 12.5 25.0 38.0 FAISS 0.8 1.5 2.2 Pinecone 5.0 12.0 18.0 召回率 top-10召回率（与精确搜索对比）： ...