先定义你的检索问题
向量检索不是「把向量存进去」这么简单。你要先回答：数据规模、更新频率、是否需要强过滤（权限、租户、时间范围）、延迟目标（P95/P99）、以及是否允许近似召回。不同产品在过滤能力、索引构建方式与一致性模型上差异很大，benchmark 往往只覆盖其中一部分。
召回与重排：向量只是第一跳
在 RAG 系统里，常见流程是 召回 → 重排 → 生成。只优化向量召回，可能忽略关键词匹配与结构化字段的优势。很多团队会采用混合检索：向量 + BM25，或向量 + 元数据过滤，再交给重排模型做精排。
如果你的业务强依赖「专有名词」或「精确编号」，纯向量检索可能经常失败，这不是「数据库不行」，而是问题不匹配。
压缩与量化：省空间也可能省召回
PQ、SQ、量化与压缩能降低成本，但会改变距离分布。上线前务必在真实查询集上对比召回率与误伤率；并记录不同版本索引的构建参数，避免「悄悄变差」。
多租户与权限：越早设计越省钱
ToB 场景常见需求是租户隔离与字段级权限。若一开始就把所有数据放进同一索引，后续再改隔离，成本会非常高。建议把权限与过滤条件纳入 schema 设计，而不是事后在应用层硬挡。
运维与可观测性：索引不是一次性产物
索引重建、增量更新、失败重试与告警都要纳入运维清单。你需要能看到：索引延迟、失败率、查询耗时分布、以及热点查询。没有可观测性，你只能等用户投诉才知道问题。
迁移策略：避免“一刀切”
当你需要更换向量数据库或索引策略时，建议采用双写与灰度读方案。先在后台同步新索引，在线上只放少量流量进行对比，再逐步扩大。这样即使新方案表现不如预期，也能快速回退，避免全站检索质量突然下降。
与业务指标的连接
最终选型不该停留在检索召回率。你还应观察下游指标：用户是否更快完成任务、工单是否减少、转化是否提升。只有把检索效果与业务结果连起来，数据库选型才算真正完成。
小结
选型时把「检索链路」画成一张图：数据从哪来、如何过滤、如何重排、如何进入模型。图清楚了，再谈哪个数据库更合适，而不是反过来。