向量数据库 vs 向量插件（以 PGVector 为代表）：工程边界与选型逻辑

一篇专门解决“到底要不要上独立向量数据库”的工程向文章

一、问题的本质

在实际工程中，向量相关需求往往是**“渐进出现”**的：

1. 一开始只是想做个 RAG Demo
2. 手里已经有 PostgreSQL / MySQL / Redis
3. 数据量看起来也不大
4. 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. 数据规模

2. 查询负载特征

3. 运维与复杂度

4. 架构弹性

六、RAG 场景下的真实分界线

在 RAG 系统中，一个非常实用的判断标准是：

“向量检索是否已经成为系统的主路径？”

可以继续用 PGVector 的情况

• 文档 < 10 万
• QPS 低
• 单租户
• 内部系统

必须上向量数据库的信号

• 文档规模快速增长
• 多模型、多 embedding
• 多用户并发提问
• 召回速度开始成为瓶颈

七、一个常见但危险的误区

“等 PGVector 扛不住了，再换向量数据库。”

这是很多系统后来被迫“推倒重来”的根源。

真正的问题不是数据迁移，而是：

• 查询接口
• 召回逻辑
• Top-K / Filter 设计
• 向量生命周期管理

都已经深度绑定在 SQL 思维中。

八、推荐的工程演进路径

阶段 1：PGVector（验证价值） 阶段 2：向量数据库（承载核心负载） 阶段 3：多向量源 / 多索引 / 多模态

关键原则：

向量插件是“起步工具”，向量数据库是“基础设施”。

九、总结

• PGVector 不是“低配向量数据库”，而是定位完全不同的工具
• 是否上独立向量数据库，取决于向量是否已经成为系统核心能力
• 选型的本质，是对未来系统形态的判断，而不是当前性能

当你的系统开始围绕“相似度”而不是“事务”运转时，就该认真对待向量数据库了。