先给结论
选型核心看数据量级与现有技术栈。原型阶段推荐用 FAISS 或 PGVector 快速验证。若业务数据已在使用 Postgres 且向量规模在千万级以内，直接用 PGVector，向量与业务同库，原生支持事务与 SQL 过滤，少维护一个系统。当数据规模达亿级以上，或需要多业务线共享、要求独立多租户向量服务时，必须选择 Milvus。FAISS 是算法库而非数据库，适合离线批量检索或作自建服务层内核。注意，后续迁移成本主要在标量过滤代码重写与运维切换，不在搬迁向量本身。
逐项对比
| 对比维度 | FAISS | PGVector | Milvus |
|---|---|---|---|
| 定位 | 算法库 | Postgres 插件 | 专用分布式向量库 |
| 强项 | 索引质量高，单机性能强 | 向量与业务同库，原生支持事务与 SQL 过滤 | 标量过滤，多租户，水平扩展，多索引类型齐备 |
| 弱项 | 无服务化，无标量过滤，无多租户 | 索引与查询性能上限低于专用库 | 依赖组件多，运维复杂度最高 |
| 典型场景 | 实验，离线批量检索，自建服务层内核 | 千万级以内，业务数据在 Postgres 的场景 | 亿级以上，多业务线共享，独立向量服务 |
| 成本 | 接入成本低，需自建周边能力 | 运维就是运维 Postgres，管理成本低 | 需专门团队维护，机器与管理成本高 |
FAISS 与两者的本质区别在于它仅是算法库，无封装的网络服务接口。它像一台裸机发动机，单机性能强且索引质量高，但在生产环境提供服务需自己实现网络层与标量过滤。因此它适合实验阶段跑数据，或在离线场景做批量检索。
PGVector 和 Milvus 是完整的数据库方案，但适用阶段不同。PGVector 的核心优势是复用现有基础设施。若业务数据已在 Postgres 中，装上插件即可实现向量与传统数据的联合查询。在千万级数据量前，其索引性能完全够用，且运维人员无需学习新系统的管理。
当业务达亿级规模，或多个业务线需要共用向量检索服务时，PGVector 的查询性能上限就会显现。此时需要引入 Milvus。作为专用分布式系统，Milvus 具备完善的水平扩展、多租户机制与多种索引类型，但代价是部署架构复杂，依赖多个底层组件，运维门槛最高。
面试怎么答
遇到这类题，先向面试官确认业务阶段与规模。建议先问两个条件：当前数据量级是否超千万，现有主库是否在用 Postgres。
获取背景后再给方案。常见错误是盲目推崇专用库，认为性能好就直接选，忽略了复杂组件带来的运维负担。合理的答题框架按阶段推演：早期验证或离线计算选 FAISS；中等规模且希望架构简单选 PGVector；面临亿级数据、需多租户管理时，才推荐部署 Milvus。最后补充，未来迁移成本主要在标量过滤逻辑的重写，证明你考虑过架构演进路线。