比"谁最快"更重要的，是先量清楚自己的负载。三条路线、三组真实数字，一次说透。
每次有人问"向量数据库选哪个"，底下就会贴出一张基准对比表。Pinecone 多少 QPS，Qdrant 多少延迟，Milvus 能撑多少亿向量。
但真正落地的时候，几乎没人是按裸 ANN 速度做决策的。
2026 年的竞争焦点早就不在"纯向量检索谁更快"了。三大开源引擎（Qdrant、Weaviate、Milvus）在过去一年里不约而同地把元数据过滤提到了索引级——Filterable HNSW、BlockMax WAND、BitMap 索引。Elasticsearch 把 BBQ 二值量化设为默认，Pinecone 在做稀疏索引，Turbopuffer 直接把索引建在对象存储上。
速度不再是唯一变量，甚至不再是主要变量。真正拉开差距的是：你的数据有多少、过滤条件多狠、写入多频繁、你愿意为运维付多少钱。
这篇不按产品序写。它按一条决策路径走——先量清楚自己的负载，再用负载去筛三条路线（Postgres 扩展 → 专用向量库 → 搜索引擎），最后拆开成本和基准这两个最容易骗人的环节。
不看产品，先看自己。向量规模、过滤选择性、写入吞吐——这三件事决定了 80% 的选型结果。
选型最常见的错误，是从"我听说某某最快"开始。正确的顺序是反过来：先量自己的负载，再让负载去挑产品。
这不是指你"计划有多少"，而是指未来 12 个月内最保守估计的生产规模。规模是选型的第一道分水岭。
"给我最相似的 10 条向量"——这是教科书式的问题。但真实业务几乎从不这么问。
真实的查询长这样："给我最近 7 天、来自美国用户、分类为技术文档的 10 条最相似向量"。三个过滤条件一加，纯 ANN 性能直接打骨折。
过滤的"狠度"可以用选择性来衡量：100 万条数据里过滤完还剩 1 万条，选择性就是 1%。选择性越低，对过滤+向量联合检索的能力要求越高。
| 过滤场景 | 选择性 | 谁更擅长 |
|---|---|---|
| 几乎不过滤（纯语义相似） | > 50% | 所有方案差距不大 |
| 中等过滤（分类、标签） | 5% – 50% | 专用库 > 搜索引擎 > pgvector |
| 强过滤（时间窗口 + 多条件） | < 5% | Qdrant (ACORN) / Elastic (ACORN-1) / Milvus 标量索引 |
Qdrant 在 1.16 里引入的 ACORN 算法很有代表性——在 5M×96d、双弱选择性过滤（约 4% 通过）下，不加 ACORN 时 `ef=64` 准确率只有 53.34%，加了之后直接拉到 97.20%，延迟 13.86ms。这不是"快一点"的问题，是"能用 vs 不能用"的区别。
写入是向量检索最容易被低估的成本项。
全量离线灌数据很简单。麻烦的是流式更新——数据每分钟都在变，索引要随时可用，查询延迟还不能抖。
有几个判断点：
VDBBench 的流式测试很说明问题：10M 向量、持续写入压力下，Turbopuffer 的 QPS 从静态 650 降到 1000 行/秒写入时的 443，降幅只有 32%；而 Milvus 从 2747 直接掉到 156，降幅 94%。对象存储架构在抗写入冲击上有天生优势——它不折腾内存里的索引结构。
"向量+关系数据在同一个库里"，这个诱惑有多大，它的边界就有多容易被低估。
pgvector 的流行不需要解释。你已经在用 Postgres，加一个扩展就有向量检索能力，不用引入新系统，不用做数据同步，不用学新 API。事务、join、备份、PITR——全是现成的。
但它不是没有边界。
pgvector 目前最新是 0.8.7（2026 年 10 月发布，修了一个 IVFFlat 的缓冲区溢出 CVE）。核心数据类型是 vector（单精度，最高 16000 维）、halfvec（半精度）、sparsevec，支持 L2、内积、余弦、L1、Hamming、Jaccard 距离。
两种索引的差别非常大：
| 指标 | HNSW | IVFFlat |
|---|---|---|
| 1M 向量内存占用 | 729 MB | 257 MB |
| 0.998 召回下吞吐 | 40.5 QPS | 2.6 QPS |
| 默认召回率 | 95%+ 开箱即用 | 75–85%，随数据漂移下降 |
| 内存开销 | 原始向量 2–5x | 约 1.1x |
| 空表支持 | 支持（无需训练） | 不支持（需先算聚类中心） |
RiveStack 的实测更扎心：2 vCPU/4GB 的小节点上，建 500 万向量的 HNSW 索引要"数小时"，100 万向量直接 OOM 失败。而 8 vCPU/16GB 的节点建 100 万向量约 9 分钟。索引构建对硬件的敏感度，远超查询本身。
满足以下全部条件时，pgvector 几乎是最优解：
这几条其实描述的是大量中型 RAG 应用的真实状态：知识库几十万到几百万条文档，查询并发不高，最重要的是语义检索结果要和用户权限、组织架构、文档分类一起过滤。
如果规模超过了纯内存 HNSW 的舒适区，但你又不想搬离 Postgres，还有两条路：
pgvectorscale（现 Tiger Data）的 StreamingDiskANN。基于微软的 DiskANN，用 Rust 实现，索引放在磁盘上，内存只缓存热点。Timescale 的基准数据显示，在 50M Cohere 768 维向量上，它做到了 471 QPS @ 99% 召回，对比 Pinecone s1 索引（同召回）p95 延迟低 28 倍、吞吐高 16 倍，成本低约 75%。
VectorChord 的 IVF + RaBitQ。1.0 版本 2025 年底发布，走的是另一条技术路线——不用 HNSW，用 IVF 加 1-bit 量化。官方基准宣称，LAION 5M 数据集上 0.95 召回的 QPS 超过 pgvector、Pinecone、Qdrant 等 3 倍以上；100M 向量建索引不到 20 分钟（16 vCPU），而 pgvector 需要 50 多小时。更新吞吐约为 pgvector HNSW 的 10 倍。
出现以下任一情况，说明你在逼近 Postgres 扩展的边界：
这些信号出现时，不用急着迁。先评估二值量化（binary quantization）和磁盘索引能不能把瓶颈往后推半年。能推就推——每多待一天在 Postgres 里，你就少一天运维两套系统的成本。
专用库不是"更快的 pgvector"。它解决的是另一组问题——规模、过滤、多租户、写入稳定性。
专用向量数据库听起来像一个品类，但内部差异极大。有的做托管 SaaS，有的做开源自托管；有的是内存型，有的建在对象存储上；有的主打低延迟，有的主打低成本。
过去两年冒出来的新玩家，走的是完全不同的路——不把索引放内存，放对象存储上。
Turbopuffer 是最典型的代表。架构是"内存/NVMe SSD 缓存 + S3 真相源"，向量 ANN 索引和 BM25 倒排索引都针对对象存储做了优化。生产规模的数据很夸张：1T+ 文档、10M+ 写/秒、25k+ 查询/秒，单命名空间最高 128B 文档。
代价是冷启动延迟——1M 文档冷启动约 500ms，召回率也略低（VDBBench 流式测试 recall 0.8352）。但成本差了一个量级：Turbopuffer 自己估算 S3+SSD 缓存方案约 $70/月，而常驻内存+3xSSD 方案约 $3,600/月，接近 50 倍的差距。
LanceDB 也是类似方向，建在 Lance 列式格式上，定位"多模态湖仓"，嵌入式运行，宣称水平扩展可达 100K QPS。
出现以下情况时，专用向量库是值得投入的：
同样重要的是知道什么时候不该上：
你可能已经在用 Elasticsearch 或 OpenSearch。如果是，向量检索能力你其实已经有了——只是没用起来。
搜索引擎做向量检索，最大的优势不是性能，是你已经在栈里了。不用引入新系统，不用做数据同步，不用学新的查询语言。
$vectorSearch 做 ANN/ENN 检索，底层是 HNSW + Apache Lucene。最大的卖点是"避免同步税"——向量和文档数据同在 MongoDB 里，不用额外同步。2025 年收购 Voyage AI 后推出了自动 embedding 和原生 reranking（$rerank），并用独立 Search Nodes 让向量负载与主库解耦。混合检索单查询内融合词法 + 向量。如果说专用向量库的王牌是"规模和过滤"，那搜索引擎的王牌就是混合检索。
纯向量检索有一个天生的缺陷：它抓不住精确关键词。用户搜"iPhone 16 Pro Max 256GB 深空黑"，纯向量检索可能会返回一堆 iPhone 相关的内容，但精确匹配那一条反而排不高。
混合检索的思路很直接：BM25（关键词匹配）跑一路，向量（语义匹配）跑一路，然后把两路结果融合起来。融合用得最多的是 RRF（Reciprocal Rank Fusion）——不看绝对分数，只看排名位置，公式是 rankScore = Σ 1/(k + rank)（默认 k=60）。
RRF 的好处是稳。它不依赖两路分数的量纲一致，对离群值和动态数据都更稳健。OpenSearch 的官方基准显示，RRF 的 NDCG@10 平均比分数归一化低 3.86%，但延迟更低、稳定性更好——用极小的相关性代价换来了工程上的可靠性。
效果提升有多大？Elasticsearch 自己的召回实验：纯 BM25 recall@10 = 0.43，混合（BM25+向量）recall@10 = 0.75，提升约 74%。Vespa 的量化实验也得出类似结论：任何混合方法都优于纯语义检索，最优混合平均高 3-5 个百分点。
厂商给的基准数字，90% 都是对的——但只在它设定的那个条件下对。换个条件，结论可能完全反过来。
最经典的例子是 Elasticsearch vs Qdrant。
Elastic 发了一篇基准，说 DiskBBQ 在约 0.97 召回时，Elasticsearch 122.6ms / 32.4 QPS，Qdrant 881.96ms / 4.52 QPS，Elastic 吞吐 7.17 倍。
Qdrant 反手发了一篇复现，说同召回（0.9596 vs 0.9599）下，Qdrant 两阶段 67.2 QPS / 59.5ms（P99 86ms），Elastic DiskBBQ 32.4 QPS / 122.6ms（P99 184.3ms）——Qdrant 吞吐 2 倍、延迟减半、算力仅 1/3。
两边都在说真话吗？很可能是的。
差别在哪？硬件配置、召回率目标、过滤条件、数据维度、查询模式……每一个变量都能让结果差出好几倍。Elastic 的测试用了网络存储，Qdrant 的测试用了本地 NVMe；Elastic 测的是高召回+过滤，Qdrant 调了参数找到了更优的平衡点。
成本也容易算错。很多人只看"每百万向量每月多少钱"，但这只是冰山一角。
真正的 TCO（总拥有成本）至少包括：
这也是为什么"Postgres 扩展"和"搜索引擎顺手做"这两条路线有天然优势——它们不新增运维对象。专用向量库虽然单价可能更低（比如自托管 Qdrant $280/月 vs Pinecone $722/月），但如果需要一个工程师花 20% 的时间来管，人力成本分分钟超过基础设施成本。
成本结构里最值得关注的变量是对象存储原生路线。Turbopuffer 和 LanceDB 这类产品把向量索引建在 S3 上，用缓存层扛热查询。它的成本结构和内存型方案完全不在一个量级——差 10 倍到 50 倍。
代价是什么？冷启动延迟（几百毫秒级）、召回率略低、生态成熟度不够。但如果你做的是"搜遍海量数据"的场景（比如全网文档、多模态内容），对延迟不那么敏感，成本优势是碾压级的。
说了这么多，最终的判断方法其实很朴素：
一周时间足够得出结论。比看十篇基准文章都准。
把三条路线的关键维度摊开，对着自己的负载直接查。
| 你的情况 | 推荐路线 | 代表产品 |
|---|---|---|
| 数据在 Postgres，向量 < 1000 万 | Postgres 扩展 | pgvector (HNSW) |
| 数据在 Postgres，向量 1000 万–1 亿 | Postgres 磁盘索引 | pgvectorscale / VectorChord |
| 向量过亿 + 强过滤 + 多租户 | 专用向量库 | Qdrant / Milvus |
| 想零运维 + 预算充足 | 托管向量库 | Pinecone / Zilliz Cloud |
| 海量数据 + 成本敏感 + 延迟可放宽 | 对象存储原生 | Turbopuffer / LanceDB |
| 已有 ES/OS + 需要混合检索 | 搜索引擎 | Elasticsearch / OpenSearch |
| 数据在 MongoDB + 需要向量 | MongoDB Atlas | Atlas Vector Search |
写这篇的时候，我翻了二十多篇基准报告和厂商博客。越翻越觉得一件事：大多数团队高估了自己需要的规模，也低估了运维一套新系统的成本。
你可能听说过"技术选型要面向未来"。但向量检索这个领域，"面向未来"很容易变成"提前优化"——为了一个可能永远到不了的规模，提前半年就上了最复杂的方案。
反过来想，Postgres 扩展撑不住了再迁，迁的成本是多少？大概一个工程师花两三周。而提前半年上专用向量库，多花的运维成本又是多少？很可能不止一个工程师两三周。
选型不是一次性的决定。它是可以迭代的。先从最简单的方案开始，等症状出现了再动，通常是更经济的选择。