去年底到今年，开沿接触的企业 AI 项目里，几乎每一个都要回答同一个问题：知识库的向量存到哪里？有人一上来就要上 Milvus 集群，结果跑了半年发现总数据量还没破百万；也有人坚持用 Excel 加 Python 内存检索，结果数据涨到几十万就崩了。
向量数据库选型其实没那么神秘，但确实容易踩两个坑：一个是「过度工程」，为还没到来的规模付出高昂的运维成本；另一个是「撞墙重做」，到了瓶颈才发现迁移成本远比想象中高。这篇文章把开沿在 RAG 项目里的踩坑经验整理出来，按规模分档给出选型建议。
1. 向量数据库到底在做什么
RAG（Retrieval-Augmented Generation，检索增强生成）的核心动作很朴素：把企业文档切片，过一遍 Embedding 模型变成几百到几千维的向量，存起来；用户提问时把问题也变成向量，去库里找最相似的几条文档片段，拼到 Prompt 里交给大模型回答。
向量数据库就是这个流程里负责「存」和「找」的基础设施。它和传统数据库的关键差别在于：传统数据库找「等于某个值」的行很快，但找「和某个向量最相似的前 K 个」就要扫全表；向量数据库通过 HNSW、IVF、PQ 等近似最近邻索引，把这个查询从 O(N) 拍到接近 O(logN)。
除了近邻检索，生产场景还会要求几样东西：
- 结构化字段过滤：只在某个部门、某个时间段、某个文档类型里检索；
- 混合检索：向量相似度 + 关键词倒排（BM25）联合打分；
- 水平扩展：单机内存放不下时能分片；
- 持久化和备份：内存索引怎么落盘、宕机怎么恢复。
5 家产品的差异，主要就体现在这几个维度上。关于 RAG 的整体落地方法，可以参考企业知识库 RAG 落地的 6 个关键决策和AI Agent 的记忆、工具与 RAG。
2. 5 家定位速览
| 产品 | 类型 | 一句话定位 |
|---|---|---|
| Milvus | 开源 | 面向超大规模的分布式向量库，云厂商也提供托管版（Zilliz） |
| Qdrant | 开源 | Rust 写的轻量级向量库，单机性能扎实，API 设计干净 |
| PGVector | PostgreSQL 扩展 | 把向量检索能力直接嵌进 PostgreSQL，零额外组件 |
| Weaviate | 开源 | 模式（schema）灵活，原生支持混合检索和模块化 Embedding |
| 腾讯云 VectorDB | 国内云托管 | 国内云生态，按量计费，合规友好 |
需要说明的是，向量数据库这个赛道还在快速演进，Pinecone、Chroma、LanceDB、阿里云 OpenSearch 向量版等也都是常见选项。这里挑出来的 5 家，覆盖了「自建-托管」「轻量-重型」「通用-国内云」几个组合，对国内中小企业项目而言比较有代表性。
3. 5 个维度横向对比
下表是开沿在做选型时常用的一张参考表，数字偏经验性，具体到你的业务还要做基准测试：
| 维度 | Milvus | Qdrant | PGVector | Weaviate | 腾讯云 VectorDB |
|---|---|---|---|---|---|
| 适用规模 | 千万-百亿级 | 百万-亿级 | 十万-百万级 | 百万-亿级 | 百万-十亿级 |
| 单机性能 | 中（强项是分布式） | 中-高 | 中（吃 PG 调优） | 中-高 | 不适用（托管） |
| 部署难度 | 高（依赖 etcd/MinIO/Pulsar 等） | 低（单二进制起步） | 极低（已有 PG 装个扩展） | 中（Docker 起步） | 零（开通即用） |
| 价格区间 | 自建只算硬件；托管随规模上万 | 自建友好；托管中等 | 几乎零额外成本 | 自建中等；托管中等 | 按量计费，PoC 阶段几百起 |
| 生态成熟度 | 中-高，社区活跃 | 中，文档清晰 | 高（PG 生态加持） | 中，模块化 | 国内 SDK/客服更顺手 |
| 合规友好度 | 自建可控 | 自建可控 | 自建可控 | 自建可控 | 国内云原生，过等保更顺 |
几个常被忽略的点：
- 部署难度的隐藏成本：Milvus 单机 Standalone 还好，集群版的运维门槛不低，对中小团队是实打实的负担；
- PGVector 的性能受 PG 整体配置影响：work_mem、maintenance_work_mem、shared_buffers 没调好，索引构建可能慢到怀疑人生；
- Weaviate 的混合检索是出厂自带，其他几家要自己拼 BM25 + 向量的两路召回。
4. 10 万向量以下：PGVector 就够，别折腾
如果你的全量文档切片之后向量数量在 10 万以下，开沿的建议非常明确：用 PGVector，别折腾。
理由有三个：
- 业务大概率已经有 PostgreSQL：再加一个组件意味着新的备份策略、新的监控、新的人员培训，运维同事会有意见；
- PG 的事务和 SQL 能力是白送的：向量召回后做权限过滤、按业务字段排序、和订单/工单数据 JOIN，PG 都能一条 SQL 搞定，专用向量库要么不支持要么很别扭；
- HNSW 在百万级以内的查询延迟完全够用：对话式 AI、内部知识助手这类场景，P95 在 100-300ms 是相对容易达到的。
开沿做过的几个内部知识库项目，从产品手册、内部 wiki、合同模板加起来，向量数量基本都在几万到几十万级，PGVector 跑得很稳。整套架构干净，AI 网关 + 大模型路由 + PG（业务表 + 向量表），就这三层。关于多模型路由的选择，可以看AI Router 多模型路由策略。
-- PGVector 的典型用法，建表 + HNSW 索引
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE doc_chunks (
id BIGSERIAL PRIMARY KEY,
doc_id BIGINT,
dept_id INT,
chunk_text TEXT,
embedding VECTOR(1024)
);
CREATE INDEX ON doc_chunks
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);
-- 带权限过滤的检索查询
SELECT id, chunk_text,
1 - (embedding <=> $1) AS score
FROM doc_chunks
WHERE dept_id = ANY($2)
ORDER BY embedding <=> $1
LIMIT 10;
5. 10 万到 1 亿：Qdrant 和 Milvus 二选一
数据量上到几百万、几千万规模，PGVector 开始吃力的信号通常是：索引构建时间从分钟拉到小时、单次查询尾延迟（P99）变得不稳定、写入吞吐被索引维护拖慢。这个阶段就要考虑专用向量库。
Qdrant 和 Milvus 是这个区间最常被对比的两家。开沿的经验是：
优先考虑 Qdrant 的场景：
- 团队是 5-15 人的小团队，运维资源紧张；
- 业务是单数据中心、单地域，暂时不需要跨机房部署；
- 强调过滤条件复杂（多字段、范围查询），Qdrant 的过滤引擎设计得很干净；
- 喜欢 Rust 生态、想要单二进制部署的简洁感。
优先考虑 Milvus 的场景：
- 已经预期会做到亿级规模，希望一次到位避免再迁；
- 团队有 K8s 和分布式系统运维经验，能 hold 住 etcd、对象存储、消息队列这一套；
- 需要多种索引类型（IVF_PQ、DiskANN 等）做不同的内存/磁盘权衡；
- 想直接用 Zilliz Cloud 托管版省掉运维。
两家都支持向量量化（标量量化、二值量化）来压缩内存占用，这对降低成本帮助不小。
6. 1 亿向量以上：Milvus 或托管型云服务
向量数量到了亿级、十亿级，问题就不再是「能不能跑」，而是「怎么扩容、怎么省钱、怎么保证 SLA」。这个阶段开沿见过的实际选择有两类：
- 自建 Milvus 集群：适合有专职 AI 基础设施团队、对成本敏感、数据合规要求高、必须自建的场景。集群规模通常起步就要 10+ 节点，etcd、Pulsar、对象存储一套都要做高可用；
- 国内云托管 VectorDB：腾讯云 VectorDB、阿里云 OpenSearch 向量版、百度 VectorDB 等。优势是开通即用，扩容是云厂商的事，按量计费在业务波动期成本更可控；合规上做等保、过监管也更顺。
亿级以上还要关注几个工程细节：
- 冷热分层：高频访问的近期数据放内存索引，历史归档数据放磁盘索引（如 Milvus 的 DiskANN）；
- 多副本读扩展：写主读从，QPS 压力大时直接横向加只读副本；
- 业务分区：按租户、按业务线物理分集合（collection），避免某一个大客户的查询把整个集群拖慢。
关于数据合规和安全的更系统讨论，可以看AI Agent 企业数据安全和AI 合规与 PIPL 的企业落地。
7. 中小企业的现实选择：先用 PGVector，撞墙再迁
开沿过去一年接触的客户里，绝大多数中小企业问的是「我应该上 Milvus 还是 Qdrant」，但实际数据量评估下来，半数以上其实根本没必要离开 PGVector。
这背后有一种常见的认知偏差：把「未来三年的理论上限」当成「现在就要支撑的容量」。结果就是：
- 团队花两到三个月部署一套 Milvus 集群，又花一个月做 SRE 培训；
- 实际跑了一年，向量数量只增长到几十万；
- 等真正撞墙的时候，集群版本已经落后两代，又要做升级和数据迁移。
更现实的路径是：
- PoC 和上线初期用 PGVector：和业务 PG 共用一套，几乎零额外成本；
- 建监控：盯住向量总数、单次检索 P95/P99 延迟、HNSW 索引构建时长；
- 当任一指标越线（如 P95 持续高于 300ms 或索引构建超过 4 小时），启动迁移评估：评估目标可以是 Qdrant、Milvus 或云上托管；
- 迁移本身是个明确的项目：两到四周窗口、灰度切流、保留回退方案。
这套打法和AI Agent 落地路线图里讲的「先跑通业务闭环再上生产级基础设施」的逻辑是一致的：基础设施服务业务，不是反过来。
8. 和现有 PostgreSQL 整合的成本
如果业务系统的核心数据已经在 PostgreSQL，向量库和 PG 之间的整合就是个绕不开的工程题。三种典型架构：
架构 A：PG + PGVector，一体化
- 优点：一套数据库、一套备份、一套权限、SQL JOIN 即可；
- 缺点：规模天花板低，PG 调优经验要求高；
- 适用：10 万到几百万向量、强 SQL/事务依赖的业务。
架构 B：PG + 专用向量库（Milvus/Qdrant），双库
- 优点：检索性能上限高，向量库可独立扩容；
- 缺点：数据双写或异步同步要处理一致性、跨库 JOIN 要在应用层做；
- 适用：千万级以上、检索 QPS 高、可接受最终一致的场景。
架构 C：PG + 云上托管向量库
- 优点：运维零负担、按量付费；
- 缺点：跨网络调用延迟比同机房高、出网带宽和合规要算清楚；
- 适用：业务在云上、PoC 阶段、不愿意自建运维。
下面这张表是开沿做选型评审时常用的快速对照：
| 架构 | 数据一致性 | 运维成本 | 性能上限 | 推荐规模 |
|---|---|---|---|---|
| A: PG + PGVector | 强一致（同库事务） | 极低 | 中 | 10 万-百万 |
| B: PG + 自建向量库 | 最终一致 | 中-高 | 高 | 百万-亿级 |
| C: PG + 云托管 | 最终一致 | 极低 | 高 | 任意（成本随规模涨） |
实际项目里，开沿见过最稳的组合往往不是最炫的那个，而是和团队能力、业务规模、合规要求都对齐的那个。
9. 决策树和决策表
一张图说清楚怎么选：
当前/12个月内向量总量预估?
├── ≤ 10万 → PGVector（直接和业务库一起）
├── 10万 - 1000万 → PGVector 起步，撞墙再迁 Qdrant
├── 1000万 - 1亿 → Qdrant（小团队）/ Milvus（有 K8s 能力）
└── ≥ 1亿 → Milvus 自建集群 / 国内云托管 VectorDB
└── 强合规/必须自建 → Milvus
└── 想省运维/按量计费 → 云托管
汇总成一张决策表：
| 你的情况 | 推荐组合 | 备选 |
|---|---|---|
| 内部知识库、几万到几十万向量 | PG + PGVector | Qdrant 单机 |
| 客户侧 RAG 应用、百万级、追求简洁 | Qdrant 单机 | PGVector |
| 多租户 SaaS、千万级、有 K8s 能力 | Milvus 集群 | Qdrant 集群 |
| 亿级以上、需要弹性扩容 | 云托管 VectorDB | 自建 Milvus |
| 强等保合规、必须本地化 | 自建 Milvus | 自建 Qdrant |
| 已经重度使用 PostgreSQL、规模不大 | PG + PGVector | 暂无必要切换 |
结语
向量数据库选型这件事，难点不在「哪个产品技术上更好」，而在「我的业务现在到底需要哪一档」。开沿这一年做下来的体感是：先用 PGVector 验证业务价值，撞墙再迁，比一开始就上分布式集群要稳得多。AI Coding 和 AI Agent 的浪潮把基础设施话题推到了前台，但工程的常识没有变——为现在的问题选合适的工具，而不是为想象中的未来过度投资。
如果你正在做 RAG 项目的选型评估，可以再看看AI Agent 厂商选型避坑和AI Agent 开发成本拆解这两篇，把基础设施成本算清楚再下决策，路会走得更稳。
