向量数据库怎么选：19 个方案的实测横评，与企业实际在用哪些的数据

上一篇开源 RAG 知识库横评里我实测了 14 个 RAG 平台的默认向量库，留下一个没展开的问题：这些向量库本身怎么选？

这篇补上。做四件事：先分类（它们不是同一类东西）→ 用两个独立数据源回答「企业实际在用哪些」（结论和赛道热度是反的）→ 逐家拆解 19 个方案 → 两张表讲清真正的技术分水岭（过滤+ANN、量化）。

文中 star、协议、版本、容器数均为 2026-09-20 实测：GitHub API + LICENSE 原文 + docker-compose + PyPI 下载量。厂商自测的性能数字一律单独标注。凡我没能从一手来源核实的，直接写「未证实」——这次有好几处，包括一整个云厂商。

一、先分类：三条主轴，解决不同问题

把 Milvus 和 pgvector 摆在一起比「谁更快」，是错的问法。它们解决的不是同一个问题。

类别	是什么	项目	你付出的代价
独立向量库	独立进程，向量是一等公民	Milvus、Qdrant、Weaviate、Vespa、Typesense、Vald、Infinity	多运维一个组件
传统库 + 向量扩展	向量只是既有引擎上的一个类型	pgvector、Elasticsearch、OpenSearch、Redis、SeekDB、MongoDB Atlas	检索能力受宿主引擎约束
嵌入式 / 零运维	进程内，无 server	FAISS、LanceDB、sqlite-vec、DuckDB VSS、Milvus Lite、Chroma(local)	无并发、无 HA、无多租户

这条分界线决定了一半的选型结论：如果你的系统已经有一个 PostgreSQL，那「再装一个 Milvus」和「加一个扩展」的成本差一个数量级——而且后者往往够用。

二、企业实际在用哪些？两个独立数据源都指向同一个答案

这是本篇最想先说的部分，因为它和「向量库赛道很热」的体感是反的。

数据源一：14 个 RAG 平台的默认向量库

我上一篇逐个解析了各家的 docker-compose、.env、pyproject.toml，统计它们的默认选择：

默认类别	平台	数量
PostgreSQL + pgvector 系	FastGPT、MaxKB、WeKnora（ParadeDB）、Khoj、R2R、LightRAG（生产推荐）	6
嵌入式（Chroma / LanceDB / FAISS）	Open WebUI、Kotaemon、AnythingLLM、Langchain-Chatchat	4
搜索引擎扩展（ES / OpenSearch）	RAGFlow、Onyx、QAnything（其一）	2–3
独立向量库（Milvus / Weaviate）	Dify（Weaviate）、QAnything（Milvus）	2

pgvector 系 : 独立向量库 = 6 : 2。 原因是 RAG 平台本来就要一个关系库存元数据、存用户、存会话——pgvector 让它们不用多运维一个组件。这不是技术优劣的选择，是运维成本的选择。

数据源二：PyPI 客户端库的真实下载量

GitHub star 是存量指标，下载量更接近装机量。我拉了各家的 Python 客户端近 30 天下载量（2026-09-20 实测）：

包	日下载	月下载
pgvector	541,663	29,885,638
weaviate-client ⚠️	358,178	19,079,055
qdrant-client	270,919	11,955,065
faiss-cpu	305,730	11,749,699
lancedb	208,829	11,213,324
chromadb	142,247	7,212,230
sqlite-vec	123,735	5,011,664
pymilvus	64,051	3,600,048
milvus-lite	18,927	1,418,309
typesense	21,680	1,083,810
usearch	53,784	581,573

两个反直觉的点：

1. pgvector 排第一，且是第二名的 2.6 倍——和 RAG 框架的默认统计互相印证。两个完全独立的数据源指向同一结论，这是本篇最稳的一条。
2. pymilvus 垫底。Milvus 是 star 最高的（46.2k），但 Python 客户端下载量排在最后——比 sqlite-vec 还低。

⚠️ 一个必须说明的坑：这组数字刚经历过一次断崖

上面那张表是「近 30 天」快照。我在别的场合复核这批数据时发现——weaviate-client 在 2026-08-25 单日暴跌 89%（1,971,744 → 224,115），之后再没起来。

真实用户不会在同一天集体消失。这是自动化流量被掐断的特征（CI / 镜像 / 爬虫）。也就是说 8-25 之前那个 300–700 万/天的量级基本是假的，之后的才可能是真实基线。

用同一时间窗重算（都取 8/25 起的 26 天，均为日均）：

包	8/1–8/24	8/25 起	变化
pgvector	1,243,925	986,046	-21%
faiss-cpu	498,915	385,098	-23%
qdrant-client	618,458	371,752	-40%
weaviate-client	3,696,964	316,290	-91% ⚠️
lancedb	544,659	262,437	-52%
chromadb	429,773	221,800	-48%
sqlite-vec	193,370	164,919	-15%
pymilvus	193,532	117,611	-39%

「weaviate-client 高于 qdrant-client」这个结论因此是错的——修正后它是 316k，落在 qdrant-client 的 372k 之下，排第 4。

三个可以带走的教训：

1. 别的包也在跌（-15% ~ -52%），但 -91% 是量级上的例外。多拉几个对照组，才能判断一个异常是「整体波动」还是「这个包独有的问题」——只测一个包会得出完全错误的结论；
2. 「近 30 天」这种滚动窗口会跨越突变点，把两个完全不同的量级平均成一个没有意义的数。看趋势，不看快照；
3. pgvector 第一这个结论在两个窗口下都成立（986k vs 372k，2.6 倍），它是稳的。这也是为什么我把它写进结论、而把 weaviate 那条撤掉。

⚠️ 但这仍然只是「下载量」这一个维度的证据，口径局限依旧成立（含 CI、传递依赖、镜像；pgvector 包只是 Python 适配库，Postgres 扩展本身走 apt/OS 包安装不计入 PyPI——所以这个数字低估了 pgvector；而它同时是 langchain-postgres 的依赖，这部分又高估了它）。别把倍数当精确比值。

⚠️ 这组数据的口径局限（必须说清）

• PyPI 下载量统计 CI、镜像站、教程复现、Docker 构建，不等于生产装机；
• 部分包是被其他框架作为传递依赖拉取的（chromadb、lancedb、faiss-cpu 尤其可疑）；
• Milvus 用户可能走 REST 或 Java/Go/Node SDK，不体现在 pymilvus 上；
• 所以这组数字只能说相对量级，不能说精确份额。

但两条独立线索都指向「pgvector 的实际装机量远超独立向量库」这一点，这个方向的结论是稳的。

三、逐家拆解

A. 独立向量库

1. Milvus —— 索引最全、规模最大，但 3.0 是刚落地的大改写

• 实测：46,166 star，Apache-2.0，Go，最后提交 2026-09-20，近 365 天 42 个 release；
• 版本有个坑：最新正式 Release 是 v3.0.1（2026-09-09）；v3.0.2 存在 git tag（09-18）且官方 standalone compose 已在用 milvusdb/milvus:v3.0.2，但 GitHub 上没有对应的 Release 条目——内容我未证实，引用时注意。2.6 线仍在并行维护（v2.6.24，09-16）；
• 部署比旧资料轻：Standalone = 3 个容器（etcd + minio + milvus）。⚠️ 旧教程说的「必须 Kafka/Pulsar」已过时——2.6 起默认 WAL 是自研的 Woodpecker（云原生、零磁盘、直写对象存储），所以不再需要 mq 容器；
• 架构说明也更新了：旧资料的「四个 coordinator + 独立 IndexNode」已过时，2.6 起合并为统一 Coordinator，IndexNode 并入 DataNode；
• 索引全集是全场最全的：稠密 FLAT / IVF_FLAT / IVF_SQ8 / IVF_PQ / IVF_RaBitQ / HNSW 系列 / DISKANN / SCANN / AISAQ（磁盘扩展，官方称 "near-zero DRAM"）/ FAISS 透传（可写 OPQ16,IVF64,PQ16x4）；稀疏 SINDI / Block-Max WAND / MaxScore；还有 GPU 索引（CAGRA / IVF_FLAT / IVF_PQ / BRUTE_FORCE）；
• 官方给的过滤建议很有用：过滤比低于 85% 用图索引，85–95% 用 IVF，高于 98% 用 FLAT（这条正好接上本站 Milvus 企业级运维 里那个「过滤越严 IVF 召回越差、HNSW 越好」的实测）；
• ⚠️ Milvus Lite 的边界要说清：pip install pymilvus[milvus-lite] 装的是独立仓库（v3.2.1），只支持 FLAT 索引、无 partition/alias/RBAC、一致性仅 Strong。不能拿 Lite 上测的结论推 standalone；
• 企业特性：多租户 4 档（Database 默认 64 / Collection 默认 65,536 支持 RBAC / Partition 1,024 不支持 RBAC / Partition Key 百万级不支持 RBAC）；RBAC 三级有；SSO 开源版没有（Zilliz Cloud 才有）；
• 坑（都是 open issue）：读路径无内存准入控制导致 standalone 并发查询 OOM、Proxy 无自保护被 OOM-kill、etcd 抖动导致 Coordinator panic；升级破坏性（2.6→3.0 有 StructArray HNSW 子字段无法加载的 open issue）。3.0 的新架构（StreamingNode / StorageV3 / Woodpecker）在 2026-09 仍有多个稳定性 issue 开着——上新版本要掂量。

2. Qdrant —— 单容器零依赖，过滤做得最细

• 实测：34,695 star，Apache-2.0 单一协议（无 BSL/SSPL 切换），Rust，最后提交 09-19；
• 部署最简单的一个：Rust 单二进制，零外部依赖，docker run 一个容器就完事。⚠️ 但不支持 NFS/对象存储作主存储，32 位系统不支持；
• 量化有 4 种（源码实证）：Scalar(int8, 4x) / Product(最高 64x) / Binary(1–2bit) / Turbo（v1.18.0 新增，官方推荐 4-bit 作多数场景默认）；
• ★ 过滤是它最有价值的部分：官方称 "in-place filtering"——既不是 pre 也不是 post，query planner 按查询在 4 条路径中动态选（filterable HNSW / ACORN / payload index / 全扫）。官方实测数字很醒目：宽值过滤召回降到 90.8%，两个宽值 AND 过滤崩到 39.7%，开 ACORN 后恢复到 100%；
• 自建版就有 JWT RBAC（role claim）。⚠️ 但官方 quickstart 原文警告：默认无加密、无认证——上线必须自己收口；
• 内存估算公式（官方）：向量数 × 维度 × 4B × 1.5。官方实测在 4GiB 限额下开 rescoring，p50 从 4.3ms 飙到 43.4ms——量化省内存不是免费的；
• 坑：升级不能跳版本（1.15 → 1.17 必须先把所有节点升到 1.16.3）；1.17 移除 RocksDB 改用 gridstore；长期 open 的 #2550「删除点后向量不回收」（2023-08 开至今）。

3. Weaviate —— 已变 Open Core，且有个数据丢失级的老 bug

• 实测：16,826 star，GitHub 标 NOASSERTION，真身是双许可（下面协议章节细讲），Go，最后提交 09-19；
• 版本：稳定 v1.39.5（09-15），另有 v1.40.0-rc.1（09-19，含 Namespaces GA、4-bit RQ）。只维护最近 3 个 minor；
• 索引 4 种（源码实证）：hnsw(默认) / flat / dynamic（flat→hnsw 自动切）/ hfresh（聚类式磁盘友好索引）。官方原话 "HNSW is an in-memory index"——HNSW 必须全内存，这是内存成本的结构性来源；
• 内存经验公式（官方）：Memory usage = 2 × 所有向量的内存占用，多出的 1 倍是 Go GC；
• ★ ⚠️ 一个数据丢失级的 known issue：read repair 会写入不完整对象——协调者把「只查了部分属性的视图」当真相写回，副本上对象丢失其余属性及向量，而对象 ID 与计数不变、健康检查完全正常。影响 1.36 及更早（从未打补丁）、1.37.0–1.37.13、1.38.0–1.38.6。这条选型时必须知道；
• ⚠️ 另一个影响所有版本的：not enough memory mappings——撞 OS 的 vm.max_map_count 上限，每个 shard 需要多个 memory mapping，大型多租户部署默认限额不够。官方建议把该值提到当前 3–4 倍。这条直接印证「一租户一 shard」在大租户数下会撞资源天花板；
• ⚠️ 能力缺口：不支持 sparse vector / SPLADE。Issue #4019（2024-01 提出，24 👍）至今 OPEN，维护者 2025-01 原话：「as far as I know, there are no short-term plans to add this」。想用 SPLADE 做稀疏检索的，直接排除；
• 多租户 = 一租户一 shard（官方原文），后果是 #4234「给 list tenants 加分页」（2024-02 开，32 评论）至今 OPEN——租户一多，连列举租户都成问题。

4. Vespa —— 能力最强也最重，K8s 是收费的

• 实测：7,100 star，Apache-2.0，Java，近 365 天 63 个 release（约 1–2 个/周，发布极频繁）；

• ⚠️ 版本号有个陷阱：最新 tag v8.753.16（09-16）对应的是 Vespa CLI，不是平台。GitHub 上的 Release 条目全是 CLI 与 Language Server，平台本身不发 GitHub Release，只打 tag + 出 Docker/RPM 制品。官方 quick-start 实测的平台镜像是 vespaengine/vespa:8.751.13；

• ⚠️ 另一个容易写错的：Vespa on Kubernetes 是商业特性。官方文档原文 "Vespa on Kubernetes is an enterprise feature"，镜像在 images.ves.pa 需要授权。自托管 K8s 得自己写 StatefulSet。正确的自建形态是 RPM 裸机 / Docker（≥4GB RAM）/ Vespa Cloud；

• ★ 过滤不是简单的前/后过滤，是三种策略带阈值（这条对选型很有用）：

  参数	默认	语义
  approximateThreshold	0.02	命中率低于此值退化为精确暴力检索
  postFilterThreshold	1.0	命中率高于此值改走后过滤（=1.0 即默认关闭后过滤）
  filterFirstThreshold	0.2	低于此值启用 filter-first（Acorn-1）

  官方明确 filter-first「improves the response time at low hit ratios but causes a dip in recall」；

• ⚠️ 没有 PQ / 标量量化。社区有 feature request 反证当前无此能力。二进制量化是靠 indexing language 的 binarize + pack_bits 两个 converter 做的，不是索引训练出来的；

• 一致性上是自认的 AP：官方明写 "Consistency requires the use of a majority consensus algorithm, which Vespa does not currently use"——不提供线性一致性；

• 企业能力基本全是 Vespa Cloud：自托管下 tenant 恒为 default 占位符、无租户隔离；SSO 仅 Cloud Enterprise；静态加密是 Cloud 专属；

• 具名用户（官网 case studies）：Perplexity（超 1,500 万月活、每周超 1 亿次查询）、Yahoo（约 150 个应用、10 亿用户量级、80 万 QPS）、Spotify R&D、Vinted 等；

• 社区规模小：Stack Overflow vespa 标签累计仅 262 个问题，GitHub 贡献者 214 人。

5. 其余独立向量库（简述）

• Typesense（26,574 star，GPL-3.0，v30.2）：内存型，官方原文 "stores the entire search index in-memory"。完全没有量化（30.2 文档 grep "quantiz" 命中 0）。Raft 全量复制、没有分片——官方原文 "will automatically replicate your entire dataset to all nodes"，加节点只提升读吞吐与可用性，不提升容量。内存公式：每维 7 字节（4B float + 约 3B HNSW 图开销，且无量化手段降低）；
• Marqo（5,031 star）：已废弃。README 原文 "Marqo's Open Source project is deprecated and will no longer receive updates"，废弃声明于 2025-11-13 由官方主动提交。主干自 2026-04-10 起零人工提交，2026-04 之后所有 push 都是 dependabot 依赖升级。⚠️ 还有一个未修复的未认证 SSRF（issue #1452，2026-07 报，至今 open，修复 PR #1464 挂着没人审），且开源版无任何认证。⚠️ 另：Marqo 2.x 已完全基于 Vespa，不再依赖 OpenSearch——2022–2023 年说「Marqo 基于 OpenSearch」的资料全过时了；
• Vald（⚠️ 正确仓库是 vdaas/vald，不是 vald-io；1,730 star）：K8s 原生微服务，极重——Helm 默认副本数加起来约 31+ 个 pod。2026 上半年近乎停滞（近 90 天 0 次提交）；
• Infinity（4,712 star，v0.7.3）：RAGFlow 母公司出品。⚠️ 纠正一个流传的说法：RAGFlow 默认后端是 Elasticsearch 不是 Infinity（.env 原文 DOC_ENGINE=${DOC_ENGINE:-elasticsearch}）。文档严重滞后——仓库 release notes 只写到 v0.5.0（2024-12），v0.6/v0.7 完全没补。

B. 传统数据库 + 向量扩展

6. pgvector —— 装机量最大的那个，但它是后过滤

• 实测：23,094 star，LICENSE 正文是标准 PostgreSQL License（宽松，近似 MIT）。⚠️ GitHub API 返回 NOASSERTION 只是因为文件没有 SPDX 标识符——别误读成「许可证不明」，这点我特别核了原文；

• 版本：v0.8.6（2026-07-29）。⚠️ 该仓库不使用 GitHub Releases，版本只能看 git tag + CHANGELOG；

• ★ 最关键的一条（README 原文）：

  With approximate indexes, filtering is applied after the index is scanned. If a condition matches 10% of rows, with HNSW and the default hnsw.ef_search of 40, only 4 rows will match on average.

  这是明确的后过滤。0.8.0 起有迭代索引扫描缓解（hnsw.iterative_scan = strict_order|relaxed_order），但这条决定了它不适合「过滤条件很窄」的场景；

• 索引只有 HNSW 与 IVFFlat 两种，无 DiskANN、无内建 SQ/PQ 索引选项。降精度只有 halfvec(fp16) 与 binary_quantize() 表达式索引两条路；

• 无内建混合检索/融合器——官方姿态是「用 PG 全文检索自己拼」；

• 不做分片：README「Scaling」节原文是 "Scale horizontally with replicas, or use Citus, PgDog, or another approach for sharding"。单机上限靠外部分片层解决；

• 多租户警告（官方）：共享近似索引会让租户间互相影响召回和速度，建议 list partitioning 或分表；

• 稳定性仍在收敛期：0.8.2 修并行 HNSW 构建缓冲区溢出、0.8.3 修 HNSW vacuum 索引损坏。

7. Elasticsearch —— 向量免费，但混合检索的 RRF 是 Enterprise 专属

• 实测：77,940 star，三重许可（下面细讲），v9.5.4（09-15）；
• ★ ★ 本篇最该记住的一条：向量检索免费，但 RRF 混合检索要 Enterprise。我在官方订阅页上核实过——免费档列的是 Retrievers: Standard, kNN, pinned, rescorer，而 Retrievers: linear, rule, RRF 与 Reciprocal Rank Fusion (RRF) for hybrid search 出现在付费档；
• 同页还能看到：Vector search / Similarity functions / Filter on ANN 免费，而 RRF / linear retriever / Rank Vectors(MaxSim) / DiskBBQ / GPU 建索引 都是 Enterprise 层；
• 含义：免费层要做 hybrid，只能自己拿 knn + query 拼 bool 再手算融合。这是个实打实的选型分水岭；
• 量化：int8_hnsw（int8）/ int4_hnsw（要求维度为偶数）/ bbq_hnsw。9.0 起 float 向量默认索引就是 int8_hnsw；自动策略是 ≥384 维走 bbq_hnsw、低于 384 维走 int8_hnsw。BBQ 官方原文：reduces each dimension to a single bit precision … reduces the memory footprint by 96% (or 32x) at a larger cost of accuracy；
• 过滤语义（官方原文）：knn 内部的 filter 是 pre-filter，「Query DSL 树里所有其它 filter 都作为 post-filter 应用」——这是个很容易踩的坑；
• ⚠️ 不要写「向量可以放 frozen tier 省钱」：官方文档没有明确 frozen tier 支持 dense_vector，这条未证实。

8. OpenSearch —— 同一件事，RRF 是免费的

• 实测：13,741 star，Apache-2.0 纯净、无附加限制，3.8.0（08-05）；
• 官方 FAQ 原文："You can use, modify, extend, embed, monetize, resell, and offer OpenSearch as part of your products and services"；
• ★ 与 ES 的对照是这篇最有用的比较之一：OpenSearch 的 RRF 免费（hybrid 自 v2.11 靠 search pipeline，两个处理器：normalization processor 做 z_score 归一化、score ranker processor 做 RRF）；
• 企业特性全部免费：opensearch-project/security 是 Apache-2.0，含传输/节点间加密、AD·LDAP·Kerberos·JWT·OIDC·SAML、集群级+索引级 RBAC + 文档级 DLS + 字段级 FLS、审计日志、GDPR/HIPAA/PCI/SOX 合规模块。无企业版分层；
• ⚠️ 但它没有 "encryption at rest"——静态加密得靠磁盘或云厂商层；
• 索引引擎 4 种：Lucene / Faiss（默认） / NMSLIB（legacy，已弃用）/ JVector（DiskANN 风格纯 Java，向量存磁盘、增量精化 codebook 无需完整重建、原生 PQ）；
• 量化：Lucene scalar / Faiss scalar / Faiss PQ / Binary / 压缩级别 2×–32× / 1-bit SQ（3.6.0 新增）；
• 注意内存熔断器：parent 默认 95% JVM heap、fielddata 40%、request 60%。向量负载下是双刃剑——大 k/大 num_candidates 容易被 break。

9. Redis —— 协议分界在版本号上，且开源版有集群天花板

• 实测：76,409 star，NOASSERTION（三选一许可），8.10.2（09-17）；

• ★ 协议按版本分界（LICENSE 原文）：

  版本	许可
  ≤ 7.2	BSD-3-Clause
  7.4.x–7.8.x	RSALv2 或 SSPLv1（2024-03 变更，催生 Valkey 等 fork）
  ≥ 8.0.0	RSALv2 或 SSPLv1 或 AGPLv3

  ⚠️ 官方口径是 "This is not a license change, but rather the inclusion of an option"——RSALv2/SSPLv1 仍保留。而 RSALv2 有一条商业限制：不得「对外提供托管服务」。选 AGPLv3 就没这条限制，选 RSALv2 就有——写合规文档时必须说清「你实际选哪个」；

• 向量检索能力在 RediSearch 里，受同一套许可约束；

• FT.HYBRID 确实存在，但自 8.4.0（2025-11-18）才有。⚠️ 任何说「Redis hybrid 早就有」的材料都是错的——此前只能自己拼 FT.SEARCH + 应用层融合。融合两种：RRF 与 LINEAR（带权重），均内建；

• ⚠️ 量化有个坑：SVS-VAMANA 的官方 Warning 原文说，Intel 的专有 LVQ 与 LeanVec 优化「not available in Redis Open Source」，非 Intel 平台与开源版会回退到基础 8-bit 标量量化——开源用户拿不到宣称的效果；

• ⚠️ 硬天花板（官方原文）：集群里一个索引的文档必须靠 hash tag 落在同一 shard，跨 shard 摊开索引需要企业版组件。另：每 schema 最多 1024 个属性，其中 TEXT 最多 128 个。

10. SeekDB（OceanBase）—— 2025 年底的新项目，注意升级限制

• 实测：2,944 star，Apache-2.0，2025-10-21 建仓（项目年龄约 11 个月），近 365 天 1,388 次提交，很活跃；
• 定位：MySQL 兼容的关系库 + 多模（关系/向量/文本/JSON/GIS），属「关系库 + 向量能力」；单二进制，无 etcd / 无 MinIO 依赖；
• 索引：HNSW（列最大 4096 维，必须全内存）/ HNSW_SQ（内存约 1/2–1/3）/ HNSW_BQ（RaBitQ，压到 1/32）/ IVF（基于表实现，不占常驻内存）/ IVF_PQ。稀疏 type=sindi 官方标注「实验特性，不推荐生产使用」；
• 差异化：单条 SQL 完成混合检索（向量 + 全文 + 标量过滤同一执行计划）、标量过滤是 pre-filter、FORK DATABASE/TABLE 内核级 COW 秒级快照；
• ⚠️ 运维上一条要命的：不支持原地升级。v1.4.0 changelog 原文要求用 OBDUMPER/OBLOADER 或 mysqldump 做逻辑迁移；
• ⚠️ 性能声明存疑：官方 launch blog 宣称 StreamingWrite「10.7× Milvus、3.2× Elasticsearch」，但官方自己的表格里 recall 仅 0.7397（低于 sync 模式的 0.7429）——厂商自测，被比较方未认可；
• 真实生产反馈样本极少，社区讨论热度低。

C. 嵌入式 / 零运维

11. FAISS —— 是库，不是数据库

• 实测：40,939 star（本组最高），MIT，v1.15.1（09-16）；
• README 定性原文："Faiss is a library"。逐条核实它的「没有」：无 server/daemon（源码树无任何服务入口）、无内置持久化/无事务（只有手工 write_index()/read_index()，无 WAL）、无元数据存储（原文：instances are represented as vectors and are identified by an integer）、过滤能力极弱（IDSelector 系列只能按 id 过滤，无 metadata 过滤）；
• 索引全集很丰富：IVF 族 / HNSW / NSG / NNDescent / PQ / RaBitQ / 二进制 / Intel SVS 集成提供的 Vamana（FAISS 里没有叫 DiskANN 的类）。⚠️ ScaNN 不在 FAISS 内，那是 Google 的独立项目；
• GPU 后端：CUDA / ROCm / cuVS / Metal（Apple，1.15.0 新增）；
• 绑定只有 C++ 与 Python。⚠️ 无官方 Java/JS/Go——issue #105「Java interface of faiss」自 2017-05-02 开到现在；
• 结论：MIT 纯算法库，无任何企业特性。生产 RAG 用它必须自建 id→原文映射、持久化、过滤、并发。

12. LanceDB —— 列存 + 多模态，但 HNSW 不是顶层索引

• 实测：11,473 star，Apache-2.0，Rust，v0.39.0（09-17，同时有 v0.40.0-beta.3）。至今仍是 0.x，无 1.0，v0.39.0 release notes 标题即含 Breaking Changes；
• 底层格式 Lance（★7,098，v12.0.0 = 09-17）：零拷贝版本化（ACID 事务 / time travel / branches，无需额外基础设施）、原生多模态 blob。Lance 同时是 DuckDB 的官方 core extension；
• ⚠️ 一个容易写错的：HNSW 不是顶层索引。官方原文 "In LanceDB, HNSW is not exposed as a top-level vector index. Instead, it's available as a substructure which further indexes the selected vectors inside each IVF partition"。当前 SDK 无独立 HNSW 或 Flat 索引类型；
• 量化：PQ(1/64–1/16) / RQ = RaBitQ(1/32) / SQ(1/4)。官方明确：查询常带 where() 过滤时应选 IVF_RQ 或 IVF_PQ，因为 IVF_HNSW_* 在过滤负载下延迟方差更高；
• 过滤默认 pre-filter（官方原文 "Pre-filtering is enabled by default"）；
• ⚠️ OSS 与 Enterprise 的差距是硬数字：对象存储延迟 500–1000ms vs 50–200ms；吞吐 10–50 QPS vs up to 10,000 QPS；OSS 无缓存、索引与 compaction 手动。Distributed search / indexing 都标 "Coming soon"。

13. sqlite-vec —— 停滞，作者说「只能用周末维护」

• 实测：8,119 star，Apache-2.0，最后提交 2026-05-18；
• 作者原话（issue #226，2025-06-26）："sqlite-vec isn't abandoned. I still intend to push update and maintain the project, but I only have time on the weekends to look after it now, since sponsorships have dried up. … sqlite-vec is far from dead."；
• 我独立核实：作者 GitHub events 显示他 2026-09-16~20 仍在活跃提交，但全在别的仓库，无 sqlite-vec 的 PushEvent。近 90 天 0 次提交，2026-06 至 09 有 15+ 个社区 PR 至今未合并；
• ⚠️ 纠正一个流传说法：稳定版 v0.1.9 是纯暴力没错，但 v0.1.10-alpha.1（2026-03-31）已加入 ANN（rescore / ivf / DiskANN），源码确认存在。但官方文档完全没写 ANN——处于「代码先行、文档缺位」状态；
• 社区已出现 fork（vlasky/sqlite-vec）。替代品 sqliteai/sqlite-vector（1,152 star）v1.1.2 = 2026-09-11，活跃。

14. DuckDB VSS —— 官方自己说别用于生产

• 实测：duckdb/duckdb-vss 仅 266 star，MIT，无任何 GitHub Release（随 INSTALL vss 分发）；
• ⚠️ 纠正一个常见误解：DuckDB 核心至今没有原生 HNSW / 全文检索。duckdb/duckdb 的 extension/ 目录只有 autocomplete、core_functions、delta、icu、json、parquet 等，无 vss、无 fts。它们是独立仓库的扩展（被官方列为 Core Extensions，INSTALL vss 一键装，容易误认为内建）；
• 索引只有 HNSW（基于 usearch），README 自述是 "an experimental extension … serves as a proof of concept"。度量仅 l2sq 与 cosine，无内积；
• ⚠️ 最关键的限制（官方原文）：HNSW 索引默认只能在内存数据库中创建，除非设 SET hnsw_enable_experimental_persistence = true；而且 "WAL" recovery is not yet properly implemented for custom indexes，崩溃可能导致索引数据丢失或损坏。官方明确 "we still recommend that you do not use this feature in production environments."；
• 补充：无增量更新——每次 checkpoint 整个索引全量序列化覆写；索引不受 buffer manager 管理、不计入 DuckDB 的 memory_limit。

15. Chroma —— Rust 重写了，但注意 OSS 与云已开始分化

• 实测：29,334 star，Apache-2.0，主语言已是 Rust（从 Python 重写），最后提交 09-18；
• 版本停了：最新 release 1.5.9（2026-05-05），约 4.5 个月无新版本。提交仍在继续，但内容全是分布式基础设施（wal3 / sysdb / work queue / Spanner）；
• ⚠️ 能力边界要看清：OSS 的全文检索是子串 + 正则（$contains / $regex，大小写敏感），不是 BM25。Sparse 向量（BM25/SPLADE）、Hybrid RRF、Collection Forking、GroupBy 全在 /cloud/ 文档区——属 Cloud，非 OSS。Issue #1330/#2513「Hybrid Search with BM25」（2023-11 提，78 👍）至今 OPEN；
• 索引：Single-Node/Local = HNSW；Distributed/Cloud = SPANN，且参数不可自定义（官方原文 "If you set these values they will be ignored by the server"）；
• ⚠️ 1.0.0 起 OSS 不再提供内置鉴权；
• ⚠️ 未修复高危漏洞：#6717「Python Backend Server Side RCE & Python Client SDK RCE」（2026-03-24 创建，至今 OPEN）；
• ⚠️ 官方自述投入倾斜（文档原文）："the majority of our engineering effort is focused on distributed Chroma and the cloud offering. As a result, local Chroma may temporarily lack some features"。开源版与云版能力已开始分化。

四、横评表

	Star	协议	最新版	部署	索引种类	量化	过滤	混合检索融合
Milvus	46.2k	Apache-2.0	v3.0.1	3 容器	最全（+GPU）	SQ/PQ/RaBitQ/AISAQ	pre + iterative	RRF(k=60) / Weighted
Qdrant	34.7k	Apache-2.0	v1.19.1	1 容器零依赖	HNSW	4 种含 Turbo	in-place + ACORN	RRF / DBSF
Weaviate	16.8k	BSD-3 + wl/	v1.39.5	1 容器	4 种含 hfresh	BQ/PQ/SQ/RQ	明确 pre	relativeScore / RRF
Vespa	7.1k	Apache-2.0	滚动 tag	config+ZK，重	HNSW	无 PQ	三阈值策略	RRF（仅 global-phase）
Typesense	26.6k	GPL-3.0	v30.2	1 容器	HNSW	无	退化为精确	0.7K+0.3S 加权
pgvector	23.1k	PostgreSQL	v0.8.6	PG 扩展	HNSW/IVFFlat	halfvec/binary	明确 post	无内建
ES	77.9k	三重许可	v9.5.4	JVM 集群	HNSW 量化系	int8/int4/bbq	knn 内 pre，其余 post	RRF（Enterprise）
OpenSearch	13.7k	Apache-2.0	3.8.0	JVM 集群	lucene/faiss/jvector	2×–32× / 1-bit SQ	检索中 / 后 / 前	RRF（免费）
Redis	76.4k	RSALv2/SSPL/AGPL	8.10.2	1 容器	FLAT/HNSW/SVS	开源版仅基础 8bit	检索期间	RRF / LINEAR
FAISS	40.9k	MIT	v1.15.1	库，无 server	最丰富的算法	PQ/RaBitQ	仅按 id	无
LanceDB	11.5k	Apache-2.0	v0.39.0	嵌入式	IVF 系（HNSW 作子结构）	PQ/RQ/SQ	默认 pre	RRF / linear / cross-encoder
Chroma	29.3k	Apache-2.0	1.5.9	嵌入式/server	HNSW（云=SPANN）	—	—	hybrid 仅 Cloud
sqlite-vec	8.1k	Apache-2.0	v0.1.9	嵌入式	暴力（alpha 有 ANN）	—	—	无
DuckDB VSS	266	MIT	随扩展	嵌入式	HNSW（实验性）	无	pre	无
SeekDB	2.9k	Apache-2.0	v1.4.0	单二进制	HNSW/HNSW_SQ/BQ/IVF	RaBitQ 等	pre	加权（可切 RRF）
Marqo	5.0k	Apache-2.0	已废弃	—	—	—	—	—

「部署」列是最小可用形态的容器数。Milvus 的 3 = etcd + minio + milvus（2.6 起不再需要 mq 容器）；集群形态各家都要多得多。

五、性能数字怎么读：三个基准，和它们各自的陷阱

横评最容易被带偏的地方就在这。我建议你在看任何向量库的性能对比之前，先把这一节读完——因为现存的主流基准没有一个能直接回答「哪个更快」。

VectorDBBench：厂商赞助，且是「等成本」不是「等硬件」

这是中文圈引用最多的榜。两个必须先知道的事实：

1. 它有利益冲突，而且自己在 README 里承认了："VDBBench is sponsored by Zilliz, the leading opensource vectorDB company behind Milvus."
2. 榜的标题是 "Vector Search Latency and QPS at 1,000 Monthly Cost"——等成本口径。各条目规格完全不同（8cu / 16c64g / 8c60g / p2.x8-1node），所以「谁的 QPS 高」实际是在问「同样花这些钱，谁更快」，不是「同等硬件谁更快」。

1M 数据集（Cohere Medium，1M × 768 float）的部分结果：

系统	P99 (ms)	QPS	Recall
ZillizCloud-8cu-perf	2	13,316	0.9383
Milvus-16c64g-sq4u	2.3	9,576	0.9189
OpenSearch-16c128g	7.2	3,055	0.9066
QdrantCloud-16c64g	6.4	1,242	0.9474
Pinecone-p2.x8	13.7	1,147	0.9262

两个值得注意的点：① Zilliz 自家 QPS 是 QdrantCloud 的 10.7 倍，但 recall 更低——榜单没藏这个；② QdrantCloud 在两个数据集上 QPS 都垫底，recall 却最高。QPS 与召回在这个榜上反向，正是「等成本 ≠ 等硬件」的直接后果。

这份榜里最有信息量的是它的持续写入压力测试（Cohere-10M，边插入边搜）。以 p99 延迟为例（阈值 98ms）：

系统	静态 p99	500 行/秒插入	1000 行/秒插入
ZillizCloud	2.1 ms	6.8 ms	10.1 ms
QdrantCloud	9.2 ms	16.2 ms	11.8 ms
ElasticCloud	10.8 ms	222 ms	—
Pinecone	14.1 ms	1,829 ms	5,992 ms

⚠️ 这是 Zilliz 跑出来的、对 Pinecone 不利的数字，属厂商自测中的竞争性数据。但它机制上说明的问题是真的：「静态 benchmark 好看」和「持续写入下还好看」是两回事，很多选型事故就出在这里。

它自己承认的方法学局限（原文）：QPS 定义是「所配置并发档中观测到的最高值」，README 明说 "VDBBench does not discover a backend concurrency limit"——它给的是下界，不是饱和吞吐。而且各 client 的默认并发档不一致（pgvector 是 1/10/20，多数是 1/5/10/20/30/40/60/80），这直接改变「最高 QPS」取值。

Big-ANN Benchmarks：唯一同时做到了硬件归一 + 覆盖过滤/流式

出处是 NeurIPS'21 和 '23 的竞赛。它的规则是硬性的：统一硬件 Azure Standard D8lds v5（8 vCPU / 16 GB DRAM），索引构建限 12 小时；streaming 赛道从 0 点起跑，插入:删除:搜索 ≈ 4:4:1，限 1 小时 + 8 GB DRAM。

NeurIPS'23 的 Filtered 赛道（YFCC-10M + CLIP，192 维 uint8，QPS@90% recall）：

名次	方案	QPS
1	Pinecone-filter	85,491
2	Zilliz	84,596
3	ParlayANN IVF	37,902
基线	FAISS	3,032

这是全文最干净的一个对照：Pinecone 与 Zilliz 只差 1.1%，而两家官网口径都是「大幅领先对手」。第三方归一化条件下的数字，和厂商叙事完全是两个量级。

⚠️ 两个注意：页面明确标注 "entries by pinecone and zilliz are not open source"——榜首两家不可复现；且 NeurIPS'23 刻意把规模压到约 10M（原文 "limiting the scale of the datasets to about 10 million points"），说明「必须上十亿才算基准」是个误解。

ANN-Benchmarks 已经停更，且它的 ground truth 不能用于过滤场景

erikbern 那个榜是很多老文章的引用来源，但 README 首句现在写的是：

At this point, ann-benchmarks is no longer actively maintained. Please consider submitting your work to different benchmarks, such as VIBE.

更关键的是口径：它的 ground truth 是「无过滤的 top-100 精确解」。所以直接拿 ANN-Benchmarks 的曲线讨论「过滤场景的召回」必然失真——这是很多横评文章犯的错。它的继任者 VIBE（DMLR 2026）口径干净得多（严格 recall-equalized，门槛 recall ≥ 0.95），但官方明确 "we do not aim to benchmark vector databases or cloud services"——它只比算法，不比数据库，所以不能用来选库。

连厂商自己都承认的事

• Qdrant 的 benchmark 页自认有偏见，原文："Are we biased? Probably, yes. … We build Qdrant and know the most about it." 但它同时给出了全文最有价值的方法论主张："in any vector search benchmark, two results must be compared only when you have similar precision. However most benchmarks miss this critical aspect." ⚠️ 而它自己表里就有这个坑：dbpedia 数据集上 milvus 的 219 rps 是在 precision 0.9973 下取的，qdrant 的 1,231 在 0.9513——差 4.6 个精度点，不是等精度比较。
• Pinecone 在自己的压测管线文章里承认："For heavy query loads, a single load-generating box can become the bottleneck before the index does."——压测客户端本身会成为瓶颈。这句出自厂商之口，比第三方指控更有分量。

所以横评该怎么做

1. 先确认精度是否可比。RPS/QPS 在不同 recall 下完全没有意义。Qdrant 的过滤榜里有一行极端例子：weaviate 6.1 rps @0.9956 vs qdrant 1,199.6 rps @0.9124——RPS 差 196 倍，但召回差 8.3 个百分点；
2. 区分「静态」和「持续写入」。前者是 demo 指标，后者才是生产；
3. 区分「等成本」和「等硬件」。前者对应采购决策，后者对应技术优劣，两个问题别混；
4. 自己跑一遍。用你自己的数据、你自己的过滤条件、你自己的 embedding 模型——用 3–5 份最烂的真实文档 + 50–100 条评测集（方法见 RAG 横评那篇第六节）。

六、协议：比 RAG 平台更脏

向量库的许可比上篇那些 RAG 平台更复杂，有四个必须读原文的地方：

1. Elasticsearch 的「免费」有很多洞

三重许可：默认全仓是「AGPLv3 / SSPLv1 / Elastic License 2.0 三选一」，只有 x-pack 目录是纯 ELv2。今天（2024-08-29 官宣「再次开源」）加 AGPL 作为并列选项，但没删除任何原有选项。

真正影响选型的是功能分层，不是协议文本：向量检索免费，RRF 混合检索 / linear retriever / Rank Vectors(MaxSim) / DiskBBQ / GPU 建索引都是 Enterprise。⚠️ 另外订阅页表头写的是 "Platinum (Existing Customers Only)"——Platinum 已不再对新客户售卖。

2. Redis 的协议分界在版本号上

≤7.2 是 BSD-3；7.4–7.8 是 RSALv2/SSPLv1；≥8.0 增加 AGPLv3 作为第三个选项。官方强调这不是「换协议」而是「加选项」——意味着 RSALv2/SSPLv1 仍然有效。

关键：RSALv2 有一条限制是「不得对外提供托管服务」。选 AGPLv3 就没有这条，选 RSALv2 就有。 用 Redis 做向量检索时，"你实际选了哪个"决定了你能做什么生意。

3. Weaviate 已经变成 Open Core

LICENSE 原文：

Outside of the "wl" directory … licensed under the BSD-3-Clause License … Within the "wl" directory and all its sub-directories … licensed under the Weaviate license … When neither is set, or the key is not well-formed, only BSD-3-Clause-licensed code is executed.

即 LICENSE_KEY 环境变量门控——不配 key，wl/ 的代码根本不会执行。这不是「开源版功能少一点」，是代码路径直接被关闭。

⚠️ 另一个值得注意的事实：公开仓库里 wl/ 目录当前只有一个 LICENSE 文件，商用代码不在公开仓库中。具体哪些功能落在 wl/ 侧，官方未公开清单——未证实。

4. Typesense 是 GPL-3.0，但官方解释得最清楚

官方 README 专门写了一段解释为什么用 GPL 而不是 AGPL，值得引用：

Typesense Server is server software and we expect users to typically run it as a separate daemon, and not integrate it with their own code. GPL covers and allows for this use case generously (eg: Linux is GPL licensed). AGPL is what makes server software accessed over a network result in derivative work and not GPL. And for that reason we've opted to not use AGPL for Typesense.

含义：以独立守护进程方式使用、不修改不分发，不触发 GPL 传染。这与 Redis（RSALv2 禁止对外托管）和 Elastic（ELv2）的约束方向完全不同。

协议汇总

约束方向	项目
宽松（MIT / Apache-2.0 / PostgreSQL License）	Milvus、Qdrant、OpenSearch、LanceDB、FAISS、Chroma、sqlite-vec、SeekDB、Infinity、pgvector
强 copyleft（GPL-3.0）	Typesense
网络条款（AGPL）	Redis 的选项之一、ES 的选项之一
Open Core 门控	Weaviate（wl/ + LICENSE_KEY）、ES（Enterprise 功能层）
非开源 / 商业限制	Redis 的 RSALv2、SSPLv1

七、技术分水岭：过滤 + ANN

如果这篇只能记一件事，记这个。 「向量检索 + 标量过滤」看起来是基本功能，实际上各家做法完全不同，而且它有一个反直觉的失效区间（下面会纠正一个常见误解）。

四种做法：

做法	代表	表现
后过滤（post）	pgvector	先扫索引再过滤，条件窄时召回崩塌
前过滤（pre）	Weaviate、LanceDB、SeekDB	先生成 allow-list 再检索，召回好但慢
检索中 / in-place	OpenSearch、Qdrant、ES 的 knn.filter	折中
动态策略	Vespa（三阈值）、Qdrant（4 条路径）	按命中率自动切换

具体数字（都是有出处的）：

• pgvector（README 原文）："If a condition matches 10% of rows, with HNSW and the default hnsw.ef_search of 40, only 4 rows will match on average."——这是明确的后过滤，靠 0.8.0 的迭代索引扫描缓解；
• Qdrant（官方实测）：宽值过滤召回降到 90.8%，两个宽值 AND 过滤崩到 39.7%，开 ACORN 后恢复 100%；
• Vespa：approximateThreshold 默认 0.02——命中率低于此值直接退化为精确暴力检索；filterFirstThreshold 默认 0.2，官方承认 filter-first「improves the response time at low hit ratios but causes a dip in recall」；
• Turbopuffer（闭源厂商的对照表）：postfilter = 0% recall / 20ms；prefilter = 100% recall / 10s；目标 = 90% recall / 25ms。它选择自己实现 native filtering（属性索引感知向量索引的聚类层级）；
• Milvus 官方建议：过滤比低于 85% 用图索引、85–95% 用 IVF、高于 98% 用 FLAT。

⚠️ 一个要纠正的常见误解：危险区间在中段，不在最严端

「过滤越窄召回越差」这个说法只在某个区间成立。VectorDBBench 的 1M 过滤测试（filterRate 从 0.5 到 0.999）给出了原数据：

过滤掉的比例	OpenSearch	Qdrant(payload index)	Turbopuffer
0.5	0.8010	0.8506	0.9350
0.8	0.6300	0.9804	0.9698
0.9	0.4914	0.9856	0.9828
0.95	0.7655	0.9906	0.9795
0.98	1.0000	0.9950	0.9681
0.999	1.0000	1.0000	1.0000

（表内为 recall。filterRate 的方向是被过滤掉的比例，我从 VectorDBBench 源码确认过：int_value = dataset_size * filter_rate。）

召回最差的是中段（过滤掉 0.5–0.95），而到了 0.98–0.999 反而回到 1.000、QPS 还上升。 原因是合理的：剩下 0.1%–2% 时候选集小到可以直接退化为精确扫描，召回必然满分，且扫描比走图更便宜。

真正的危险区间是「过滤掉一半到九成」这一段——此时候选集既不够小到能暴力兜底，又已经被削得让图索引断连。学术侧也有定量刻画：post-filter 的崩塌点约在 s ~ k/K，图内过滤的崩塌点约在 s_c ~ 0.83/M（M 是图的度，度越大越能扛）。

更极端的选择性下，有些实现是「完全失效」而不是「变差」：SIGMOD 的一篇实验（选择性扫到 0.1%）发现 Faiss-HNSW 在 0.1% 选择性下 fails completely，ACORN 同样失败，SeRF/DSG 也失败；而 Milvus 靠分区机制在 0.1% 仍能服务、Faiss-IVFPQ 在所有数据集上都能处理 0.1%（作者归因：HNSW 的单调收敛限制了探索，IVF 非单调反而能扩搜）。

还有一个只在论文里被记录的代价：ACORN 的召回优势是拿构建成本换的。LAION-25M 上 ACORN-γ 建索引 38,007 秒 vs HNSW 1,147 秒（约 33 倍）。只看 QPS 的评测会完全掩盖这一项。

⚠️ 最后是最大的一个坑：过滤场景的 ground truth 必须用「带同一谓词的暴力解」。VectorDBBench 的 GT 是随过滤条件走的（源码确认），学术基准也多如此；但 ANN-Benchmarks 的 ground truth 是无过滤的 top-100 精确解——拿它的曲线讨论过滤召回必然失真。另外，有一篇 2025 年的论文专门批判「平均召回」这个指标：均值会掩盖 query 间方差，让均值好看的系统在困难 query 上崩掉，主张用 Robustness-δ@K（recall 超过 δ 的 query 占比）。

本站已经实测过这个陷阱：Milvus 企业级开发运维方案 §3 那组数据——过滤越严 IVF 召回越差（0.125→0.066）而 HNSW 越好（0.562→1.000），且延迟不变所以监控发现不了。那里有完整的实测方法，这里不重复。

落到选型上：

• 如果你的查询会过滤掉一半到九成数据（比如按租户 + 时间范围 + 状态，命中几千条），这是最危险的区间。pgvector 明确是后过滤，Milvus/Qdrant/Vespa 这类有动态策略的才对；
• 如果过滤后只剩几百条甚至更少，反而安全——多数实现会退化为精确扫描，召回满分（代价是延迟）；
• 如果很少过滤、纯语义检索，后过滤的代价可以忽略，pgvector 的运维优势就压过一切；
• 验收时必须按「过滤掉的比例」扫一组曲线（0.5 / 0.8 / 0.9 / 0.95 / 0.98 / 0.999），而不是只测一个点。这个坑在 demo（无过滤、数据量小）里永远不会暴露。

八、第二道分水岭：量化能力差异极大

内存成本是向量库的第一大成本。量化决定你能把多少向量塞进同样一台机器。

库	量化手段	压缩比
Qdrant	Scalar / Product / Binary / Turbo	4x / 64x / 32x / 可配
Milvus	IVF_SQ8 / IVF_PQ / RaBitQ / AISAQ	4x / 显著 / 高 / 磁盘
Weaviate	BQ / PQ / SQ / RQ(Rotational)	1-bit RQ 约 32x；4-bit RQ 约 8x
Elasticsearch	int8 / int4 / bbq	int8 4x、bbq 32x
OpenSearch	Lucene/Faiss scalar、Faiss PQ、Binary	压缩级别 2×–32×
SeekDB	HNSW_SQ / HNSW_BQ(RaBitQ)	2–3x / 1/32
pgvector	halfvec(fp16) / binary_quantize()	2x / 32x
LanceDB	PQ / RQ(RaBitQ) / SQ	1/64–1/16 / 1/32 / 1/4
Typesense	完全没有	—
Vespa	无 PQ / 无标量量化（只有 converter 做二值化）	—
Redis	HNSW/FLAT 无量化参数；开源版 SVS 回退到基础 8-bit	—

四个要点：

1. 压缩比的分母是 float32。表里所有「Nx」都是相对 4 字节/维算的。如果你的入库流程已经用 fp16，实际收益要打对折。 而且各家算召回时有没有开 rescore / oversampling 并不统一，横向比较这些倍数意义有限；
2. ⚠️ 反直觉：PQ 通常是「更省内存但更慢」，不是更快。 Weaviate 的实测：Gist 数据集上 PQ 低参配置延迟从 2,133µs 涨到 7,521µs（慢 3.52 倍），内存只从 4,218MB 降到 1,572MB。原因是 PQ 的距离计算非 SIMD 友好，比 SQ 慢（Milvus 官方也确认「PQ 在同压缩率下召回常优于 SQ，但 SQ 更快」）。「量化 = 加速」是个错误直觉；
3. 「省内存」和「可生产」是两个不同的阈值。Qdrant 官方实测（1M × 100 维 glove）：全内存约需 1.2GB；只 mmap 向量时 OOM 阈值降到 600MB，但内存低于 1000MB 后 RPS 从 687 掉到 25；向量 + HNSW 图都 mmap 时，135MB 就能服务 100 万向量——但只有 0.33 RPS（每次查询 3 秒）。官方原话是这「makes it impossible to use the system in production」。另有一条官方经验规则：内存里少放一半向量，搜索延迟大约翻倍；
4. Weaviate 有个结构性成本：官方明说 "HNSW is an in-memory index"，且内存经验公式是 2 × 向量内存（多出的 1 倍是 Go GC）。没有量化时它的内存开销是同类里偏高的。

附：内存估算公式（选型做预算时直接用）

组件	公式	出处
原始向量	点数 × 副本 × 维度 × 每维字节（fp32=4 / fp16=2 / uint8=1）	Qdrant 容量规划
HNSW 图（Qdrant）	点数 × m × 2 × 4 × 1.2（m 默认 16；1.2 覆盖下层与记账）	Qdrant 容量规划
HNSW 图（FAISS）	每向量 (维度×4 + M×2×4) 字节，M ∈ [4,64]	FAISS wiki
HNSW（原论文）	每元素 (Mmax0 + mL·Mmax) × 每连接字节，mL ≈ 1/ln(M)；索引本体典型 60–450 字节/对象	arXiv:1603.09320
RaBitQ	(维度/8 + 8) 字节/向量（1-bit 变体）	FAISS wiki
DiskANN PQ 码预算	向量字段大小(GB) × pq_code_budget_gb_ratio	Milvus 文档
总预留	再加 20% headroom；节点数 ceil(总内存 / (单节点内存 × 0.8))	Qdrant

Milvus 官方给的 1M × 128 维算例（可直接感受量级差）：IVF-PQ 无 refine 11.0 MB ｜ IVF-PQ + 10% 原始向量 refine 62.2 MB ｜ IVF-SQ8 131.0 MB ｜ HNSW 640 MB ｜ HNSWPQ 136 MB ｜ IVF-FLAT（不压缩）515.0 MB。

注意最后两行的对比：同一个 HNSW，加 PQ 量化后内存从 640MB 降到 136MB，官方标注相对原始向量是 64x 压缩——这就是量化在内存成本上的分量。

九、混合检索的融合方式，各家不一样

上篇提过 RRF，这里要补一个重要的纠正：不是所有「混合检索」都走 RRF。

平台	默认融合
Milvus	RRF（k 默认 60）/ Weighted（arctan 归一化）
Qdrant	RRF（k 默认 60）/ DBSF
Weaviate	relativeScoreFusion（v1.24 起默认） / rankedFusion(RRF)
Elasticsearch	RRF（Enterprise）/ linear（Enterprise）
OpenSearch	z_score 归一化 + score ranker(RRF)，免费
Typesense	加权排名融合 0.7K + 0.3S，不是 RRF 也不是分数归一化
Redis	RRF / LINEAR（带权重），FT.HYBRID 内建
Vespa	RRF 作为 rank feature 组合，只能放 global-phase
Azure AI Search	RRF（k 为小常数，实验上约 60）
Turbopuffer	服务端 RRF（rank_constant 默认 10，可带 per-subquery 权重）
SeekDB	默认加权，可切 RRF（rank_constant: 60）
pgvector	无内建，自己拼

为什么这件事重要：RRF 只看排名不看分数，对分数分布不敏感；而加权/归一化融合对分数尺度很敏感——不同检索器的分数分布差异大时，加权融合会系统性偏向某一路。换库时如果只对比「有没有混合检索」而不对比融合算法，很容易得到一个错误的结论。 融合的数学见本站那篇 多路检索与 RRF。

十、选型决策

如果只记四句话：

1. 绝大多数场景，pgvector 就够了。 两个独立数据源都指向这一点——RAG 框架默认值 6 : 2，PyPI 下载量在剔除掉那个断崖后仍是第二名的 2.6 倍。别被赛道热度带偏：多引入一个组件的运维成本，通常大于它带来的性能收益。
2. 唯二需要考虑换独立向量库的理由：① 查询会过滤掉一半到九成数据（pgvector 是明确的后过滤——README 原文：条件命中 10% 行时，HNSW 默认 ef_search=40 平均只返回 4 行）；② 数据量大到单机撑不住（pgvector 不做分片，要 Citus/PgDog 之类外挂）。
3. 验收时按过滤比例扫一组曲线（0.5 / 0.8 / 0.9 / 0.95 / 0.98 / 0.999），再加一组混合检索用例。这两件事的差异在 demo（无过滤、纯语义、数据量小）里完全暴露不出来，却决定生产可用性。⚠️ 危险区间是中段，不是最严端——见 §7。
4. 看任何性能对比前，先确认两边精度是否可比。 RPS 在不同召回下没有意义，这是横评里最容易犯的错（详见 §5）。

⚠️ pgvector 具体是怎么失效的

「pgvector 撑不住」是个太粗糙的说法。真正有用的是一组具体机制——多位互相独立的工程师报告过同一批原因：

机制	表现	出处
查询规划器放弃 HNSW	在半选择性过滤下，Postgres 稳定选了 prefilter 计划，「根本没用上 HNSW 索引」	Mem0 CTO（该团队最终迁走）
HNSW 构建吃内存	几百万向量上建 HNSW 可能吃掉 10+ GB 内存，且是在你在跑的生产库上、持续数小时	Alex Jacobs《The Case Against pgvector》
autovacuum 导致召回衰减	不盯着调 autovacuum，召回会大幅下滑；且索引巨大、难以 vacuum	Halcyon 工程师
量化跌精度	试过 fp16 / int8 / binary，精度都下降，最终退回全精度	Sentry 工程博客

边界大致在哪： 一位 GCP 的 ScaNN 作者称，生产环境里的 pgvector HNSW 典型落在 0–1000 万向量区间。多个迁移案例（Mem0、Linear、以及 Reddit 的选型评估）都落在这条线附近。

⚠️ 但这些「迁移收益」数字全部来自新东家的客户故事页，没有第三方审计，也没有一条公布召回率或内存的绝对值。 机制可信，收益幅度存疑。

反面证据必须并列（否则就成了唱衰）：

• Sentry 在生产上跑住了 pgvector——768 维、端到端 sub-100ms、新 issue 创建量降 40%，且这是署名工程师的公开复盘，可信度高；
• 有开发者在 1000 万规模说「没有大问题」，也有在数千万条、过滤到 5 万条后查询约 10ms 的报告；
• Qdrant 自己的员工都建议：先用手上已有的方案，随复杂度增长再换专用引擎。

所以正确的表述是：pgvector 的边界在「千万量级 + 多租户/窄过滤」这个组合上，不是「pgvector 撑不住」。而且这个边界高度依赖你的过滤选择性——所以下面这件事比记数字更重要。

把迁移触发条件写进设计文档

别等线上变慢了才开会讨论。选型时就把「什么情况下该换」写成可判定的条件，出现即触发评估，而不是靠感觉：

• 尾延迟连续超出业务目标（不是偶发抖动，是连续）；
• 过滤后召回无法达标（按 §7 那组曲线扫，看是不是掉在中段）；
• 索引维护开始影响业务写入（建 HNSW 时业务库被拖慢）；
• 恢复窗口超过允许范围（备份/恢复时间超出 SLA）。

配套要求：维护一套固定的评测集（真实语料 + 真实查询 + 真实过滤条件），换库时用同一套去比——否则你是在拿两份不同试卷的分数做决策。

这条实践来自一篇同行的选型文（开沿科技：向量数据库怎么选），它全文不给任何性能数字、只给判断框架，这个克制本身值得学——「没有真实压测产物的精确 QPS，看起来很专业，实际上最容易误导决策」。

参考

实测数据来源（2026-09-20）：

• GitHub REST API：star / license / pushed_at / language / releases
• LICENSE 原文经 raw.githubusercontent.com 直读：pgvector、Weaviate、RediSearch、ES、Open WebUI 等
• PyPI 下载量：pypistats.org/api/packages/{pkg}/recent（30 天快照）与 /overall（181 天日线，用于看趋势与突变点；两者时间窗不同，不可混用）
• 官方订阅/定价矩阵：Elastic Subscriptions（RRF 分层已逐行核实）

基准测试：

• VectorDBBench 榜单（⚠️ README 自认由 Zilliz 赞助；等成本口径）｜VectorDBBench 仓库
• Big-ANN Benchmarks（NeurIPS'21/'23，唯一硬件归一 + 含过滤/流式赛道）
• ANN-Benchmarks（已停止维护）｜继任者 VIBE（只比算法，不比数据库）
• Qdrant Benchmarks（官方自认有偏见）｜Qdrant pre/post filtering 博文（过滤召回对照表）
• Pinecone 压测管线（厂商自认「压测客户端会先成为瓶颈」）
• 学术：Robustness-δ@K 对平均召回的批判 (arXiv:2507.00379)｜SIGMOD 属性过滤实验 (arXiv:2508.16263)｜Filtered ANNS 统一基准 (arXiv:2509.07789)｜HNSW 原论文 (arXiv:1603.09320)｜ACORN (arXiv:2403.04871)｜RaBitQ (SIGMOD'24, arXiv:2405.12497)

官方文档与源码：

• Milvus 3.0 索引说明｜Milvus 过滤检索｜Milvus 多租户
• Qdrant 量化｜Qdrant pre/post filtering 博文｜Qdrant 内存分层
• pgvector README（过滤与迭代扫描）｜OpenSearch k-NN 方法与引擎
• Vespa binarizing vectors｜Vespa K8s 为商业特性
• LanceDB 向量索引｜DuckDB VSS｜Chroma 架构
• Turbopuffer native filtering（过滤召回对照表）
• Weaviate 官方定价｜Onyx Enterprise Edition

本站相关：

• 姊妹篇：中小企业开源 RAG 知识库怎么选（本文「默认向量库」统计的出处）
• Milvus 入门：从起一个实例到混合检索
• Milvus 企业级开发运维方案（★ 过滤 + ANN 召回陷阱的完整实测）
• 多路检索实战：三通道架构与 RRF 融合
• RAG 的现状、老问题，以及那条「像素方案」

声明：本文无厂商合作。star 数、协议条款、版本号、下载量均为 2026-09-20 实测快照。 性能数字特别说明：文中所有 benchmark（SeekDB 的「10.7× Milvus」、Milvus 3.0 的「SINDI 10× MaxScore」、OpenSearch 的「ingestion 快 4.2×」、Turbopuffer 的「1T+ 文档」等）均为厂商自测，被比较方未认可，请勿直接当作横向对比结论。 本次调研的明确缺口（如实告知，未做填补）：GCP 全线不可核实——cloud.google.com 等域名在本环境网络层不可达，尝试通过公共中继绕行被安全策略拒绝，故 Vertex AI Vector Search / AlloyDB / Cloud SQL pgvector / BigQuery vector search 一条都没能验证；华为云 GaussDB 向量能力全站反爬，同样未取证；Reddit r/vectordatabase 全域连接重置，社区痛点取不到（取不到 ≠ 没有）。凡未能一手核实的，正文已标「未证实」。