上个月帮一个创业团队看数据架构，他们要做智能客服。聊到大模型接入这一步，团队内部吵起来了。后端想直接上独立向量库，理由很直接——专库专用，性能没话说。DBA不干，说再加一套集群谁来维护，现有关系库已经有向量能力了不用白不用。
我翻了他们的需求文档，心里大概有数了。知识库五万条左右，文档切chunk生成embedding，每天新增几百条，高峰每秒二三十次查询。放在三年前，这个规模只能选独立向量库。现在不一样了。
我把两种方案的真实代价拆了一遍，写在这篇文章里。看完你自己判断。
独立向量库：从真香到真麻烦
独立向量库刚出来的时候确实解决了大问题。关系型数据库那时候根本不支持向量，你要做相似度搜索，只能把embedding存进Milvus、Pinecone或者Weaviate里。
刚上线那阵子大家都觉得爽。等真正跑生产了，麻烦就来了。
数据一致性是第一道坎。业务数据在关系库，向量在另一套系统。用户改了商品描述，业务表更新了，向量得重新生成再写进去。两套系统之间没有事务，中间那几秒到几分钟的窗口里，搜索返回的结果可能是旧的。之前一个电商团队因为这个吃了大亏，用户搜到的价格和实际对不上，投诉电话都打爆。
运维是第二道坎。多一套集群就多一套监控、一套备份策略、一套故障排查流程。出问题的时候翻两套系统的日志，定位时间直接翻倍。创业团队一共就几个后端，一个人盯两套数据库已经很够呛了。
费用这块也得想清楚。云服务的向量库按存储量和查询量计费，数据涨上去后账单涨得比业绩还快。自建呢，硬件加人力算下来其实也省不了多少。
独立向量库本身没啥问题，ANN算法成熟，分布式扩展也强。关键是你得想清楚，你的业务到底用不用得到这些能力。
关系型数据库做向量，现在到底什么水平
如果你要存几百万维的高维向量、每天跑亿级查询、要求毫秒级响应，那独立向量库确实更合适。不过说实话，大部分业务根本到不了这个量级。
现在主流关系型数据库基本都支持向量了。在关系表里加一个向量列，同一张表里既有业务字段又有embedding，查询的时候一条SQL把精确过滤和向量相似度搜索一起做了。
大概长这样。一条SQL 同时做结构化过滤和向量相似度检索：
SELECT id, product_name, price, similarity_score
FROM (
SELECT id, product_name, price, stock,
vector <=> '[0.23, -0.15, 0.87, ...]' AS similarity_score
FROM products
WHERE category = '电子产品'
AND status = '在售'
AND price BETWEEN 1000 AND 5000
) AS filtered
ORDER BY similarity_score DESC
LIMIT 5;
这个查询做的事情：先用category、status、price把范围缩下来，再对筛选后的结果做向量相似度排序。整个过程在一个库内完成，不用先在关系库查一批ID，再去向量库查embedding，最后在应用层拼起来。
融合方案的核心点就在这——一条SQL同时处理结构化条件和非结构化语义匹配。
这个方案的好处不用多解释。数据和向量在一个库里，事务天然一致。业务表更新向量跟着更新，不会出现两边对不上的情况。运维盯一套集群就行，备份恢复走同一条路。团队也不用重新学一套新系统。
性能方面，关系型数据库的向量索引已经不是试验品了。关键一点是HNSW索引在关系库里的实现方式和独立向量库没有本质区别——都是多层图结构，通过逐层缩小候选集范围来加速最近邻搜索。区别在于，独立向量库里HNSW是核心卖点，关系型数据库里它是众多索引类型中的一种，和B-tree、GiST、GIN共享同一套优化器框架。
HNSW加IVF混合索引，底层用SIMD指令集加速计算，部分产品还支持GPU协处理。实测下来，百万级向量的相似度检索在毫秒级别，日常业务场景够了。
我测过KingbaseES的向量能力，它在关系型数据库基础上融合了JSON文档、向量、GIS空间和时序这几类处理能力。多种数据类型在同一张表定义，事务和备份走同一套链路。跨模查询一条SQL搞定，不用跨库协调。更重要的是它的向量索引是内核级集成，不是外挂扩展——向量引擎和查询优化器、事务管理器深度整合，支持亿级向量数据实时入库，写入不丢ACID。KES Sharding组件还提供大规模并行的分片能力，数据量上去了可以横向扩展。
不过实话说，关系库做向量和独立向量库比，在极端场景下确实有差距。十亿级向量检索、自定义距离度量、动态索引重建这些场景，独立向量库的专门优化更深。但绝大多数业务到不了这个量级，关系库的向量能力完全够用。
数据库吸收新能力的历史反复上演过。JSON 文档存关系库当年也有人质疑，现在已经是标配。向量只是又一次同样的轨迹——先是独立产品探路，成熟后被主流关系型数据库吸收为内置类型。这次不同的是，AI 应用的数据规模远没有当年 NoSQL 面对的极端场景那么多，所以吸收的速度会更快。
