一篇专门解决“到底要不要上独立向量数据库”的工程向文章
一、问题的本质
在实际工程中，向量相关需求往往是**“渐进出现”**的：
- 一开始只是想做个 RAG Demo
- 手里已经有 PostgreSQL / MySQL / Redis
- 数据量看起来也不大
- PGVector 一装，SQL 一写，就能跑
于是问题来了：
“既然 PGVector 已经能做向量搜索了，为什么还要上 Milvus / Qdrant 这种独立向量数据库？”
要回答这个问题，关键不在功能，而在系统边界。
二、核心结论先行（一句话版）
向量插件解决的是“把向量能力嵌入现有数据库”，而向量数据库解决的是“以向量为核心的数据系统”。
两者不是性能高低的关系，而是：
- 职责边界不同
- 设计哲学不同
- 可扩展路径完全不同
三、什么是“向量插件”（以 PGVector 为例）
1. 定义
向量插件的本质是：
在传统数据库中，引入一种新的数据类型（vector）和相关算子。
PGVector 做的事情非常明确：
- 提供
vector(n)类型 - 提供距离函数（L2 / cosine / inner product）
- 提供向量索引（IVFFlat / HNSW）
它并没有改变 PostgreSQL 的核心架构。
2. PGVector 的工程优势
（1）系统复杂度极低
- 不引入新组件
- 不引入新运维体系
- 不引入新一致性模型
（2）事务 + 向量天然一体化
BEGIN;INSERTINTOdocs(id,content,embedding)VALUES(...);COMMIT;这是独立向量数据库很难做到的。
（3）SQL 是巨大的生产力工具
- JOIN
- 子查询
- 权限
- 备份
全部现成。
3. PGVector 的隐含前提
但 PGVector 能成立，是有隐含前提的：
- 向量规模有限（通常 < 百万）
- 相似度查询不是主负载
- 系统瓶颈仍然在业务逻辑而非向量搜索
当这些前提不再成立，问题就会显现。
四、什么是“向量数据库”（Vector-First System）
1. 向量是“一等公民”
在向量数据库中：
- 数据模型围绕 vector 设计
- 存储、索引、缓存都为向量服务
- 查询的第一目标是 Top-K 相似度
这与“在数据库里加一列 vector”有本质区别。
2. 架构层面的根本差异
以 Milvus / Qdrant 为例：
- ANN 索引是核心数据结构
- 支持索引异步构建
- 搜索参数可调（ef / nprobe）
- 可针对向量搜索单独扩容
这些能力，在 PostgreSQL 架构中几乎不可能自然生长出来。
3. 工程目标不同
向量数据库的核心目标是：
在可接受误差下，把相似度搜索做到极致的快、稳、可扩展。
因此它们天然接受：
- 近似结果
- 最终一致
- 计算 / 存储分离
五、关键维度的正面对比
1. 数据规模
| 维度 | 向量插件（PGVector） | 向量数据库 |
|---|---|---|
| 万级 | 轻松 | 轻松 |
| 百万级 | 勉强可控 | 常规场景 |
| 千万级 | 风险极高 | 正常 |
| 亿级 | 不现实 | 设计目标 |
2. 查询负载特征
| 特征 | PGVector | 向量数据库 |
|---|---|---|
| 偶发相似度查询 | ✅ | ✅ |
| 高频 Top-K | ❌ | ✅ |
| 并发搜索 | ❌ | ✅ |
| 搜索是核心业务 | ❌ | ✅ |
3. 运维与复杂度
| 维度 | PGVector | 向量数据库 |
|---|---|---|
| 部署复杂度 | 极低 | 中等~高 |
| 运维成本 | 极低 | 明显 |
| 学习成本 | SQL 即可 | 新 API / 新模型 |
4. 架构弹性
| 能力 | PGVector | 向量数据库 |
|---|---|---|
| 独立扩容向量层 | ❌ | ✅ |
| 索引与存储解耦 | ❌ | ✅ |
| 多租户向量服务 | ❌ | ✅ |
六、RAG 场景下的真实分界线
在 RAG 系统中，一个非常实用的判断标准是：
“向量检索是否已经成为系统的主路径？”
可以继续用 PGVector 的情况
- 文档 < 10 万
- QPS 低
- 单租户
- 内部系统
必须上向量数据库的信号
- 文档规模快速增长
- 多模型、多 embedding
- 多用户并发提问
- 召回速度开始成为瓶颈
七、一个常见但危险的误区
“等 PGVector 扛不住了，再换向量数据库。”
这是很多系统后来被迫“推倒重来”的根源。
真正的问题不是数据迁移，而是：
- 查询接口
- 召回逻辑
- Top-K / Filter 设计
- 向量生命周期管理
都已经深度绑定在 SQL 思维中。
八、推荐的工程演进路径
阶段 1：PGVector（验证价值） 阶段 2：向量数据库（承载核心负载） 阶段 3：多向量源 / 多索引 / 多模态关键原则：
向量插件是“起步工具”，向量数据库是“基础设施”。
九、总结
- PGVector 不是“低配向量数据库”，而是定位完全不同的工具
- 是否上独立向量数据库，取决于向量是否已经成为系统核心能力
- 选型的本质，是对未来系统形态的判断，而不是当前性能
当你的系统开始围绕“相似度”而不是“事务”运转时，就该认真对待向量数据库了。
