14.07-向量数据库选型

要点

向量数据库选型的真正冲突不是「哪个产品更好」，而是团队对规模变化的预期和当前运维能力之间的错位
向量数据库的核心价值是 ANN 索引——HNSW 和 IVF 是两种主流算法，分别优化召回率和内存效率，选方案本质上是在选索引实现
pgvector 在百万向量以下是务实选择，专用向量数据库（Qdrant/Milvus）的优势在百万以上才真正体现
过滤策略（预过滤 vs 后过滤）和混合检索能力是功能表上看不到的关键差异，却直接影响 RAG 检索质量
选型要把迁移成本当作长期承诺来评估——向量数据库之间没有标准迁移协议，换方案意味着重建索引、迁移数据、验证召回率
选型不是找最强方案，而是在数据规模、运维能力和现有技术栈三个约束条件下找最优解

1. 向量都生成好了，存在哪里

索引链路走完了。文档解析好了（14.02），文本切成了 chunks（14.05），每个 chunk 已经用 Embedding 模型转成了向量（14.06）。下一步是把向量存进去，支持高效的相似度检索。

这个步骤看起来只是一个存储决策，实际上它是 RAG 系统里第一个真正影响线上性能的架构选择。

冲突通常长这样：团队已经在用 PostgreSQL，向量规模目前只有几十万条。用 pgvector 扩展现有的 PG 实例，听起来顺理成章。但你知道半年后向量规模可能到千万级，那时候 pgvector 的延迟还能撑住吗？反过来，如果直接上 Milvus 集群，当前几十万条向量要用的运维能力、部署复杂度，是不是杀鸡用了牛刀？

向量数据库选型的核心误区是相信存在通用最优解。 每个方案都有自己发挥优势的工程约束——数据规模、运维能力、现有技术栈。选错了方向比选错了产品代价大得多。

这一节帮你建立选型的判断框架：搞清楚比什么、怎么比、你的约束条件指向哪个方向。后续的 14.08（pgvector）、14.09（Qdrant）、14.10（Milvus）会分别展开每个方案的完整实践。

2. 向量数据库到底「专用」在哪里

选方案之前，先搞清楚向量数据库和传统数据库在检索能力上的分界线。这个分界线决定了你是否真的需要专用向量数据库。

传统数据库用 B-tree 做精确匹配和范围查询，全文检索引擎用倒排索引做关键词匹配。向量检索需要的是另一种东西：近似最近邻（ANN）算法——在高维空间里快速找到距离查询向量最近的几个点。精确最近邻在高维下性能指数级退化（维度灾难），ANN 算法选择接受微小的召回率损失，换取几个数量级的速度提升。

主流的 ANN 算法分两大阵营：

HNSW（Hierarchical Navigable Small World） 基于多层图结构。上层稀疏用于快速定位区域，下层密集用于精确搜索。查询延迟低、召回率高，代价是内存占用大、索引构建慢。

IVF（Inverted File Index） 系列先把向量空间聚类分区，查询时只搜索目标区域及其邻居。内存效率好，但需要调参（nlist、nprobe），召回率在参数不当时不如 HNSW。

选向量数据库，本质上是在选这些索引算法的实现质量和可配置程度。 不同方案的差异在于：HNSW 的实现变体（是否支持图剪枝、量化压缩）、是否提供 IVF 系列变体、过滤在索引搜索之前还是之后执行、索引是否可以卸载到磁盘。

这些差异在数据量小时感知不到。但当向量数超过百万、查询并发上到几百时，索引实现的差异直接反映在查询延迟、内存占用和运维压力上。理解了底层机制，比对照功能列表更容易做出正确决策。

3. 三类方案和淘汰逻辑

在逐个对比之前，先建立一个淘汰框架——什么情况下你根本不需要专用向量数据库。

向量数据库是专门优化向量检索的存储方案。但如果你的向量规模不超过百万、不需要复杂的过滤和混合检索、团队已经有 PostgreSQL 运维能力，那么 pgvector 就够用了。引入专用向量数据库意味着新增一个组件、一套运维流程、一个可能的迁移负担——这些成本需要有明确的收益来对冲。

已经用 PostgreSQL 且向量规模 < 百万？
│
├── 是 → pgvector（第 14.08 节展开）
│
└── 否 → 需要混合检索、复杂过滤、多租户隔离、分布式能力？
         │
         ├── 是 → 专用向量数据库
         │        │
         │        ├── 有运维能力 → Qdrant 或 Milvus（14.09 / 14.10）
         │        └── 无运维能力 → Pinecone 或 Qdrant Cloud
         │
         └── 否 → Cloudflare Vectorize 等轻量托管

这个决策树的核心判断是：先用 pgvector 跑通，除非有明确理由必须引入专用方案。 很多团队踩过的坑是一开始就上 Milvus，结果数据只有几千条，运维成本远超数据本身的价值。

正确的路径是：pgvector 验证全链路 → 性能确实成为瓶颈时 → 评估迁移到专用方案。引入新组件的代价必须有明确的收益来对冲。

4. 统一维度对比

用五个维度建立比较框架：查询性能（延迟和吞吐）、数据规模上限（能承载多少向量）、运维复杂度（部署和维护成本）、总体成本（软件 + 硬件 + 人力）、生态集成（SDK、API、与现有技术栈的兼容性）。

比较功能列表没有意义。同样的方案，在十万级向量和千万级向量下的最优选择可能完全不同。 必须在具体规模场景下对照：

维度	pgvector	Qdrant	Milvus	Pinecone	Vectorize
索引算法	HNSW / IVFFlat	HNSW（优化实现）	IVF_FLAT / IVF_SQ8 / HNSW 等	自研索引（不透明）	HNSW
延迟（百万级）	10-50ms	5-20ms	5-20ms	10-30ms	15-40ms
规模上限	百万级（受 PG 架构约束）	数十亿	百亿级	数十亿	千万级/索引
混合检索	✅（配合 PG 全文检索）	✅（稀疏 + 稠密向量）	✅（多种融合策略）	✅（稀疏向量）	❌
过滤策略	SQL WHERE（后过滤）	预过滤 + 后过滤	预过滤 + 后过滤	预过滤	基础 metadata 过滤
多租户	按 schema / RLS	namespace	partition key	namespace	namespace
部署方式	PG 扩展	自托管 / Cloud	自托管 / Zilliz Cloud	全托管	Cloudflare 托管
运维成本	低（复用 PG 运维）	中（独立组件）	高（依赖 etcd + MinIO + Pulsar）	零	零
软件成本	免费	开源免费	开源免费	按存储 + 查询计费	免费层 + 按用量
生态	PostgreSQL 生态	REST / gRPC / 多语言 SDK	gRPC / 多语言 SDK	REST / 多语言 SDK	Workers 生态

延迟数据为经验区间，非基准测试结果。 实际延迟受维度数、过滤条件、并发量和硬件配置影响。这里的数值用于量级判断，不用于方案间精确对比。

这张表的关键信息：pgvector 的运维成本最低但规模天花板也最低；专用向量数据库的运维成本高但能力和规模上限远超 pgvector；托管服务零运维但长期成本和灵活性受限。

没有一行是全绿的。选型就是在这些维度之间做取舍。

5. 核心能力差异：索引、过滤与混合检索

上一节的维度对比覆盖了「有什么」，这一节拆解真正拉开差距的三个能力层。

5.1 索引机制的实现质量

同样标称支持 HNSW，不同方案的实现差异很大。HNSW 的图构建质量、ef_construction 参数范围、是否支持图剪枝优化、是否支持量化压缩（SQ8、PQ）以节省内存——这些细节决定了同等召回率下的查询延迟，和同等延迟下的内存占用。

pgvector 的 HNSW 实现从 0.5.0 版本开始支持，功能完整但调参选项有限。Qdrant 的 HNSW 实现在大量生产场景中验证过，默认参数在多数场景下就能给出好结果。Milvus 提供多种索引类型（IVF_FLAT、IVF_SQ8、IVF_PQ、HNSW、ANNOY 等），可以根据数据特征选择最合适的算法。

5.2 过滤策略：预过滤 vs 后过滤

这个差异在功能表上通常看不出来，但对 RAG 场景影响巨大。

带过滤条件的向量检索（比如「只在 document_id = X 的 chunk 中搜索」）有两种执行策略：

后过滤——先做向量检索取 top-K，再用过滤条件筛选。过滤条件严格时，可能过滤掉大量结果，实际返回的数量远少于请求的 K。

预过滤——先用过滤条件缩小搜索范围，再在子集上做向量检索。返回数量可控，但过滤后的子集太小可能导致索引效率下降。

pgvector 用 SQL WHERE 做后过滤，配合 pgvector 的 WHERE 子句使用时，实际返回数量可能不稳定。Qdrant 和 Milvus 同时支持预过滤和后过滤，让你根据场景选择。做 RAG 的时候，top-K 的数量直接影响上下文质量，过滤策略的选择决定了你能不能稳定拿到足够的结果。

5.3 混合检索能力

把稀疏向量（如 BM25 转化）和稠密向量融合检索，能显著提升 RAG 的检索质量——语义搜索和关键词搜索互补各自的盲区。

pgvector 可以配合 PostgreSQL 的全文检索做混合查询，灵活度取决于 SQL 能力。Qdrant 原生支持稀疏向量 + 稠密向量的融合检索，配置简单。Milvus 支持多种融合策略。Pinecone 近期也加入了稀疏向量支持。Vectorize 目前不支持混合检索，这是它最大的能力短板。

6. 规模驱动的性能对比

五个维度的静态对比之后，换一个视角——按数据规模看哪个方案在什么阶段开始掉队。

规模	推荐方案	关键判断
10 万以下	pgvector / Vectorize	所有方案都能轻松应对，选运维成本最低的
10-100 万	pgvector	pgvector 仍在舒适区，开始关注索引参数调优
100-1000 万	Qdrant / Milvus	pgvector 性能拐点——延迟上升、索引构建变慢；专用方案优势开始体现
1000 万-1 亿	Qdrant 集群 / Milvus	Qdrant 过滤性能和混合检索成熟；Milvus 分布式能力开始发挥
1 亿以上	Milvus	只有分布式架构能原生支撑，Milvus 的存储计算分离设计在这个规模是核心优势

运维成本和方案能力通常成反比。 pgvector 复用现有 PG 运维，最友好；Qdrant 和 Milvus 需要独立维护集群、处理版本升级、容量规划；Pinecone 和 Vectorize 零运维，但在灵活性和长期成本上付出代价。

成本结构的差异也值得注意。开源方案（pgvector、Qdrant、Milvus）软件免费，成本在硬件和人力。托管服务（Pinecone、Vectorize）零软件成本，但大规模场景的存储 + 查询费用增长很快。十万级以下托管服务最便宜；百万级开始自托管方案的总体成本更优；千万级以上开源方案的长期成本优势明显。

7. 选型陷阱与迁移路径

7.1 三个常见陷阱

陷阱一：过早优化。 数据只有几千条就上 Milvus 集群。运维成本远超数据本身的价值，团队精力花在部署而不是业务上。正确做法：先用 pgvector 跑通全链路，性能不够时再迁移。

陷阱二：只看功能不看运维。 Qdrant 和 Milvus 功能强大，但需要团队有分布式系统经验。Milvus 依赖 etcd（元数据）、MinIO/S3（对象存储）、Pulsar/Kafka（消息队列），任何一层出问题都会影响集群稳定性。没有这个能力，选托管服务或 pgvector 更务实。

陷阱三：忽视迁移成本。 向量数据库之间没有标准迁移协议。从 pgvector 迁移到 Qdrant 需要重建索引、迁移 metadata、验证召回率一致性。从 Pinecone 迁出的难度更高——API 适配、数据导出格式、索引重建都需要重新适配。选型时要把迁移成本当作长期承诺来评估。

7.2 迁移路径与回退策略

向量数据库选型不是一次性决策。数据规模增长、用户需求变化、团队能力演进，都可能触发重新评估。

pgvector ──── 规模增长 ────→ Qdrant（过滤 + 混合检索最强）
   │                            │
   │                            ├── 规模继续增长 → Milvus
   │                            │
   │                            └── 想减少运维 → Qdrant Cloud
   │
   └─── 想减少运维 ────→ Pinecone / Vectorize

降低迁移成本的关键是抽象接口层。 在业务代码和向量数据库之间建立一层抽象——定义统一的 VectorStore 接口（upsert、search、delete），业务层只依赖接口，具体实现由对应的 adapter 提供。这样迁移时只需要替换 adapter 层，业务逻辑不需要改。

typescript

// 向量存储接口——业务层只依赖这个接口
interface VectorStore {
  upsert(points: VectorPoint[]): Promise<void>
  search(query: SearchQuery): Promise<SearchResult[]>
  delete(ids: string[]): Promise<void>
}

// 具体实现按需替换
class PgvectorStore implements VectorStore { /* ... */ }
class QdrantStore implements VectorStore { /* ... */ }
class MilvusStore implements VectorStore { /* ... */ }

从托管服务迁出的成本通常高于从自托管方案迁出。 Pinecone、Vectorize 的数据导出和 API 适配都需要额外工作。选择托管服务前，确认数据导出能力，并评估最坏情况下的迁移成本。

8. 决策矩阵与分场景推荐

你的约束	推荐方案	理由
已有 PostgreSQL，向量 < 百万	pgvector	复用现有运维能力，零额外组件
需要复杂过滤 + 混合检索，规模百万-千万	Qdrant	过滤性能和混合检索能力在专用方案中平衡最好
超大规模（亿级），有分布式运维能力	Milvus	唯一能原生支撑百亿级向量的开源方案
无运维能力，需要快速上线	Pinecone / Qdrant Cloud	全托管，按量计费
Cloudflare 生态，小规模快速集成	Vectorize	Workers 原生集成，免费额度慷慨

回退信号： 如果你选的方案开始频繁出现延迟抖动、索引构建时间线性增长、或者运维占据超过 20% 的工程时间，是时候评估迁移了。

向量数据库选型没有通用赢家。选型的本质是在数据规模、运维能力和现有技术栈三个约束条件下找最优解。 对大多数团队来说，从 pgvector 开始验证全链路是最务实的起点——等性能、功能或规模真正成为瓶颈时，再迁移到专用方案也不迟。迁移成本不低，但提前抽象接口层可以把它控制在可接受范围内。

下一篇（14.08）展开 pgvector 的具体实践——安装、索引选择、查询优化和混合检索配置。

14.07-向量数据库选型 ​

要点 ​

1. 向量都生成好了，存在哪里 ​

2. 向量数据库到底「专用」在哪里 ​

3. 三类方案和淘汰逻辑 ​

4. 统一维度对比 ​

5. 核心能力差异：索引、过滤与混合检索 ​

5.1 索引机制的实现质量 ​

5.2 过滤策略：预过滤 vs 后过滤 ​

5.3 混合检索能力 ​

6. 规模驱动的性能对比 ​

7. 选型陷阱与迁移路径 ​

7.1 三个常见陷阱 ​

7.2 迁移路径与回退策略 ​

8. 决策矩阵与分场景推荐 ​