传统关系型数据库 VS 专门向量数据库：我们真的需要 Milvus 吗？

随着生成式 AI 项目的落地，几乎所有研发团队都要面对一个技术选型问题：是用我们熟悉的关系型数据库（如 PostgreSQL + pgvector 扩展），还是去部署一套全新的专门向量数据库（如 Milvus, Qdrant）？

对于中小团队来说，引入新的中间件意味着运维成本、监控复杂度以及数据同步代价的上升。本文将从架构设计、性能实测和运维复杂度三个维度，客观剖析这两大选型方案。

1. 架构本质的区别：共享内存 VS 计算分离

1.1 传统数据库的向量扩展（以 pgvector 为例）

PostgreSQL 的 pgvector 插件采用的是一体化存储方案。

• 数据模型：向量直接作为关系表中的一个列字段存储，可以使用普通的 SQL 进行增删改查。
• 计算机制：索引与普通 B+ 树索引类似，驻留在 PostgreSQL 的共享内存中。查询时由 PostgreSQL 的查询规划器（Query Planner）统一调度。

1.2 专门向量数据库（以 Milvus 为例）

Milvus 采用的是分布式、读写分离、计算与存储分离的云原生架构。

• 数据模型：数据划分为 Collection、Partition、Segment，支持向量与有限的标量混合存储。
• 计算机制：通过 Coordinator 协调器、Query Node 计算节点、Index Node 索引节点和 Data Node 存储节点进行协同。检索计算被高度并行化并卸载到专用的计算节点（甚至支持 GPU 加速）。

2. 性能实测数据对比

针对大规模高维向量数据集，我们进行了基准评测。

实验参数：

• 数据规模：1000万条 768维 向量（标准中等规模文本嵌入）
• 测试硬件：16核 CPU, 64GB 内存（独立实例部署）
• 召回率目标：指定检索的 Recall@10 必须稳定在 90% 以上

评测结果：

数据来源参考自开源基准项目 VectorDB Bench。

3. 技术选型决策树

究竟该怎么选？我们建议通过以下几个边界条件进行决策：

3.1 建议选择 pgvector（传统关系型数据库）的场景：

1. 数据规模小：您的向量数量在 100 万以下。
2. 应用处于原型期：首要目标是快速验证业务逻辑，不需要复杂的运维。
3. 强关系型事务要求：需要保证向量更新与关系表业务数据的强 ACID 事务一致性。

3.2 建议选择 Milvus / Qdrant（专门向量数据库）的场景：

1. 千万级以上数据量：向量数据随时间快速增长，单机内存无法承受。
2. 极高的并发要求：在线服务并发检索量大，响应时间（Latency）敏感在 10ms 以内。
3. 云原生架构与水平扩展：需要支持 Kubernetes 部署、自动缩容扩容以及副本高可用。

4. 总结

没有绝对完美的架构，只有最契合业务的选型。在项目启动初期，使用 PostgreSQL + pgvector 可以帮助团队以极低的资源和运维代价跑通业务；但当业务迎来爆发增长、数据量突破千万门槛时，迁移到专用的向量数据库（如云原生的 Milvus）将是保证系统可用性的必然选择。