1. 选型之前先想清楚你到底在解决什么问题向量数据库这两年热度一直居高不下很多团队一上来就问“选 Milvus 还是选 pgvector”但真正做过几个线上项目之后你会发现这个问题本身就问错了。选型的起点从来不是“哪个数据库更火”而是“我的业务到底在解决哪一类检索问题”。我接触过的场景大致分三类。第一类是纯语义检索比如知识库问答、文档相似度匹配用户输入一句话系统要找出语义上最接近的若干条内容这类场景对向量检索的召回率和延迟要求都很高但数据量往往在百万到千万级别。第二类是混合检索既有结构化字段的过滤条件比如时间范围、类目、权限标签又要做向量相似度排序这类场景在电商、内容平台里特别常见。第三类是传统业务里“顺手加一点向量能力”比如给已有的用户表加一个兴趣向量字段用来做简单的相似用户推荐数据量不大但不想为此再维护一套独立系统。这三类场景对应的选型答案完全不同。第一类往往需要专业向量数据库第二类要看过滤条件的复杂度和数据规模第三类大概率用普通数据库的向量扩展就够了。所以我在做选型时第一步永远是先把业务问题归类而不是先看 benchmark 榜单。还有一个容易被忽略的点向量检索从来不是孤立存在的。它通常和元数据存储、业务事务、权限校验绑在一起。如果你只盯着“谁的 QPS 高”很容易选出一个检索性能很好、但和现有业务系统集成起来极其痛苦的方案。我自己就踩过这个坑后面会详细讲。2. 普通数据库的向量能力到底能做到什么程度2.1 pgvector 这类扩展的真实定位很多人对普通数据库做向量检索的印象还停留在“只能做玩具级 Demo”这个认知其实已经过时了。以 PostgreSQL 的 pgvector 扩展为代表现在它支持 HNSW 和 IVFFlat 两种索引能覆盖相当一部分生产场景。pgvector 的核心价值在于“不引入新系统”。你的业务数据本来就在 PostgreSQL 里加一个 vector 类型的列建一个 HNSW 索引就能在同一个事务里完成“插入业务数据 写入向量 查询相似内容”。这种一致性是独立向量数据库很难做到的因为跨系统写入必然涉及分布式事务或者最终一致性的取舍。它的适用边界也比较清晰。我实测下来在单表向量数据量 100 万到 500 万、维度在 768 到 1536 之间、过滤条件不算特别复杂的场景下pgvector 配合 HNSW 索引查询延迟可以稳定在几十毫秒级别。这个性能对大多数中小型业务已经够用了。但它的短板同样明显。第一是索引构建速度HNSW 索引在百万级数据上构建可能要几十分钟甚至更久而且构建期间对内存占用很高。第二是过滤和向量检索的结合效率当过滤条件筛选出的候选集很小、但向量索引又必须先扫描大量数据时查询计划可能退化。第三是水平扩展能力PostgreSQL 的分片方案相对复杂不像专业向量数据库那样原生支持分布式。2.2 什么情况下普通数据库就够了我给一个比较实用的判断标准如果你的向量数据量在千万级以下过滤条件以简单的等值或范围查询为主团队已经在用 PostgreSQL 或类似的数据库并且没有专门的向量检索运维人力那优先考虑普通数据库的向量扩展。这个判断背后有几个理由。首先是运维成本多维护一套系统意味着多一套监控、备份、扩容、故障处理流程这些隐性成本在小团队里往往被低估。其次是数据一致性向量和业务数据放在一起省去了同步逻辑也避免了“向量库里有、业务库里没有”这种脏数据问题。最后是开发效率SQL 生态成熟调试、排查、迁移都有现成工具。我见过一个内容推荐项目向量数据大概 200 万条团队一开始上了独立向量数据库结果发现每天要花大量时间处理数据同步延迟和一致性问题后来换回 pgvector整体复杂度下降了一大截检索性能反而因为少了网络跳转而更稳定。2.3 普通数据库做向量检索的典型配置如果你决定用 pgvector有几个配置点值得注意。维度选择上1536 维是很多 embedding 模型的默认输出但如果你能用 768 维甚至 384 维达到相近效果索引体积和查询延迟都会明显下降。索引参数上HNSW 的 m 和 ef_construction 需要根据数据量和召回率要求调m 一般取 16 到 32ef_construction 取 64 到 200。查询时的 ef_search 参数直接影响召回率和延迟的权衡。ef_search 越大召回率越高但延迟越大。我的经验是先用一个中等值比如 100跑通再根据实际召回率测试结果微调。注意pgvector 的 HNSW 索引在数据频繁更新时会有性能衰减因为每次更新都要维护图结构。如果你的向量数据写入非常频繁要考虑批量写入或者定期重建索引。3. 专业向量数据库的核心优势在哪里3.1 分布式架构带来的规模上限专业向量数据库最核心的差异化能力是原生分布式。以 Milvus 为例它把存储、计算、协调拆成独立组件可以按需水平扩展。当你的向量数据从千万级涨到十亿级甚至百亿级时这种架构优势就体现出来了。我参与过一个图像检索项目向量数据量在 8000 万左右维度 512。用单机方案时索引加载就需要大量内存查询延迟在高峰期波动很大。换成分布式向量数据库后通过分片把数据分散到多个节点查询延迟稳定了很多扩容也只需要加节点。这种规模下普通数据库基本就力不从心了。不是不能做而是性价比太低——你要么堆非常昂贵的单机硬件要么自己实现一套复杂的分片逻辑维护成本远超直接用一个成熟方案。3.2 专用索引和量化技术专业向量数据库在索引算法上的投入也更深。除了 HNSW 和 IVF 系列它们通常还支持乘积量化PQ、标量量化SQ等压缩技术能在牺牲少量召回率的前提下大幅降低内存占用。这个能力在数据量大的时候非常关键。举个例子1000 万条 1536 维的 float32 向量原始内存占用大约是 1000 万 × 1536 × 4 字节接近 60GB。如果用 PQ 压缩到原来的四分之一甚至更少就能在同样的硬件上装下更多数据或者用更少的机器支撑同样的规模。量化带来的召回率损失需要实测评估。我的经验是在大多数语义检索场景下适度的量化对最终业务指标的影响很小因为用户对“第 8 条和第 9 条结果的顺序差异”通常不敏感。但如果你的场景对召回率极其敏感比如法律文书检索那就要谨慎使用高压缩比。3.3 混合检索和过滤能力专业向量数据库在“向量检索 结构化过滤”这个组合上的优化通常更成熟。它们支持在向量索引层面就结合过滤条件避免先检索大量候选再过滤的低效路径。这个能力在电商场景里特别重要。比如“在某个类目下、价格区间内、库存大于零的商品中找出和用户浏览历史最相似的商品”过滤条件可能筛掉 99% 的数据。如果先做向量检索再过滤效率会非常低而专业向量数据库可以把过滤条件下推到索引扫描阶段。不过这里有个细节要注意不同产品对过滤和向量检索的结合方式不一样有的是先过滤再检索有的是边检索边过滤实际效果要看你的过滤条件选择性。选择性高的过滤条件能筛掉大部分数据适合先过滤选择性低的则相反。4. 选型决策的五个关键维度4.1 数据规模和增长预期这是最硬性的指标。我一般按当前数据量和未来一年的增长预期来评估。如果当前在百万级、一年内预计不超过千万级普通数据库扩展通常够用。如果当前就在千万级以上或者增长很快专业向量数据库更稳妥。这里有个容易犯的错误只看当前数据量忽略增长曲线。我见过一个项目上线时只有 50 万条向量团队选了单机方案结果半年后数据涨到 3000 万迁移成本非常高。所以选型时一定要把增长预期纳入考虑宁可稍微超前一点。4.2 查询延迟和吞吐要求延迟要求决定了你能接受什么样的索引和部署方式。如果要求 P99 在 10 毫秒以内那基本只能考虑内存索引加专业向量数据库普通数据库很难稳定达到。如果 P99 在 100 毫秒以内可以接受那选择空间就大很多。吞吐要求则决定了是否需要分布式。单机方案的 QPS 上限通常在几百到几千具体取决于维度和索引参数。如果业务峰值 QPS 要求上万那分布式几乎是必选项。4.3 过滤条件的复杂度过滤条件越复杂、选择性越高专业向量数据库的优势越明显。如果你的查询基本都是“纯向量检索没有过滤”那普通数据库的劣势会被缩小。反之如果每次查询都带一堆过滤条件就要重点评估候选方案在混合检索上的表现。4.4 团队运维能力这一点经常被技术选型忽略但实际影响很大。专业向量数据库通常组件更多、配置更复杂需要专门的运维知识。如果团队里没有人熟悉分布式系统的运维贸然上专业方案可能会在故障处理时手足无措。我的建议是如果团队规模较小、没有专职基础设施人员优先选择运维简单的方案哪怕性能上做一些妥协。系统稳定运行比峰值性能更重要。4.5 生态和集成成本最后要考虑的是和现有系统的集成成本。如果你的业务重度依赖 SQL、事务、复杂 join那普通数据库扩展的集成成本会低很多。如果你的业务本身就是微服务架构各个组件独立部署那引入专业向量数据库的边际成本就没那么高。下面这张表是我在实际选型时常用的对照框架供参考维度普通数据库扩展专业向量数据库适用数据规模百万到千万级千万到百亿级运维复杂度低中到高数据一致性强同库事务需额外同步机制混合检索能力一般强水平扩展较弱原生支持延迟表现中等优秀团队门槛低中到高5. 实操中的踩坑记录和排查思路5.1 索引参数调优的常见误区很多人建完索引就不管了这是大忌。HNSW 的 ef_search 参数在查询时是可以动态调整的不同业务场景可能需要不同的值。我一般会做一组召回率测试找出满足业务要求的最小 ef_search 值这样能在保证效果的前提下把延迟压到最低。另一个误区是盲目追求高召回率。召回率从 95% 提到 99%延迟可能翻倍但业务指标未必有感知。要先明确业务能接受的召回率下限再倒推参数。5.2 数据同步延迟的处理如果用独立向量数据库数据同步是绕不开的问题。常见方案是业务写入数据库后通过消息队列异步同步到向量库。这个链路里任何一环出问题都会导致数据不一致。我的处理经验是第一同步逻辑要有幂等设计避免重复写入第二要有对账机制定期比对两边的数据量和关键字段第三对一致性要求高的场景考虑双写加补偿而不是纯异步。5.3 内存和成本的平衡向量检索是内存密集型操作。数据量大的时候内存成本可能超过计算成本。这时候量化技术就很重要但量化参数需要实测调优。我一般会先用小批量数据测试不同量化配置下的召回率找到可接受的压缩比再应用到全量数据。5.4 常见问题速查问题现象可能原因排查方向查询延迟突然升高索引未加载到内存检查内存占用和索引状态召回率下降量化压缩过度调整量化参数或换索引类型过滤后结果为空过滤和检索顺序问题检查查询计划调整过滤策略写入变慢索引维护开销考虑批量写入或延迟建索引内存持续增长索引碎片或缓存泄漏检查索引重建策略和缓存配置6. 一个可复现的选型验证流程与其纠结理论不如做一次小规模验证。我的做法是准备一份贴近真实分布的数据集规模控制在真实数据的十分之一左右然后分别在候选方案上跑同一组查询记录延迟、召回率、资源占用。验证时要注意几点查询集要覆盖真实场景的各种类型包括纯向量检索、带过滤的检索、高并发场景指标要同时看 P50 和 P99平均值会掩盖长尾问题资源占用要算上索引构建阶段不能只看查询阶段。跑完验证之后把结果和业务要求对照通常答案就很清晰了。如果两个方案都满足要求就选运维更简单的那个如果都不满足就回到需求本身看看是不是要求定得太高或者数据规模需要重新评估。我个人在实际操作中的体会是选型这件事没有标准答案只有适不适合。同样一个业务团队背景不同、增长预期不同最优解可能完全不一样。与其追新不如把业务需求拆清楚把验证做扎实答案自然会浮现出来。