向量数据库项目怎么选：先看场景，不看跑分

向量数据库选型不应从 benchmark 排名开始。个人项目、企业知识库和高并发检索承担的部署、过滤、备份与扩展责任不同，同一个“最快”结论无法跨场景成立。

四个候选先做仓库审计

| 项目 | 技术栈/形态 | release、tests、docs、demo | 许可 | | --- | --- | --- | --- | | pgvector | PostgreSQL 扩展，C 为主 | Releases、test、README/安装与 SQL 示例 | PostgreSQL License | | Qdrant | Rust 向量服务 | Releases、tests/CI、文档、Quickstart | Apache-2.0 | | Weaviate | Go 服务与模块生态 | Releases、test、文档、示例 | BSD-3-Clause | | Milvus | Go/C++ 等组成的分布式系统 | Releases、tests/CI、文档、部署示例 | Apache-2.0 |

仓库材料按 2026-07-15 核验。它们能证明项目公开了相应能力入口，不代表本站完成性能或故障实测。

个人项目：先减少系统数量

如果已有 PostgreSQL、数据规模和并发都有限，pgvector 往往能减少备份、权限和监控的新增责任。先验证过滤、索引构建和查询计划；不要因为专用数据库功能更多就提前拆服务。

企业知识库：过滤与治理优先

部门、文档版本、租户和权限会让元数据过滤成为核心。Qdrant、Weaviate 等候选应使用同一批真实过滤条件比较，同时检查快照、备份、删除和升级路径。召回率高但无法解释数据生命周期，不适合进入企业方案。

例如一套两万份文档的知识库并不算“海量”，但每份文档同时有部门、密级、版本和生效日期。用户查询时先做权限过滤，再做语义召回；管理员撤权后，旧会话和缓存也不能继续显示结果。这个场景的难点不是单次最近邻查询，而是过滤选择性、更新一致性与审计。

试验要准备两个用户、三个部门和一份被撤销文档。分别比较新增后可见、撤权后不可见、旧版本失效、恢复后权限仍正确。若候选只在无过滤数据上更快，不能支持选型。反过来，pgvector 即使延迟略高，只要现有 PostgreSQL 权限、备份和团队经验能减少整体责任，也可能是更合理方案。

高并发与大规模：运维能力一起选

Milvus 等分布式方案提供扩展路径，也带来更多组件、资源和故障面。只有容量、吞吐或隔离需求已经超过简单部署，且团队能承担监控、升级和恢复时，分布式架构才可能合理。

共同测试集

为所有候选准备相同向量、元数据和查询：语义近似、精确关键词、部门过滤、版本失效、删除后不可检索。记录索引时间、查询延迟分布、召回判断、资源占用、备份恢复和运维步骤。没有实测时不填性能数字。

上手成本的差异

pgvector 的成本主要在 PostgreSQL 版本与索引理解；Qdrant/Weaviate 增加独立服务；Milvus 需要面对分布式部署。第一次评估应按复杂度递增，前一层已经满足需求就停止。

benchmark 不能替你回答什么

公开基准无法覆盖你的过滤比例、文档更新、硬件、并发模型和恢复目标，也很少替你计算值班成本。它可以帮助形成候选，不应直接决定采购或架构。

常见失败：先迁移，再定义问题

团队看到专用向量库的性能图，先把数据迁走，随后才发现真实瓶颈是文档解析、embedding 请求或权限过滤。另一种失败是只测新增和查询，不测更新、删除、备份与恢复，结果系统在第一次文档改版时必须全量重建。

避免方法是保留现有方案作为基线，把每个候选只用于解决一个明确缺口。例如 PostgreSQL 查询计划已经证明过滤与延迟不满足目标，才引入 Qdrant 或 Weaviate 对照；容量和单机恢复已经成为实测瓶颈，才评估 Milvus 的分布式责任。没有基线失败证据，就没有迁移理由。

替代方案和投入顺序

pgvector 的替代不是另一款向量数据库，也可以是关键词检索、混合检索或减少文档范围；Qdrant、Weaviate 的托管版可以替代自托管，但会改变数据和成本责任；Milvus 之前还可比较其轻量部署路径或现有搜索系统的向量能力。

投入顺序应从复用现有 PostgreSQL 开始，再到单体专用服务，最后才是分布式系统。pgvector 适合已有 PostgreSQL 的小中型基线；Qdrant 或 Weaviate 适合需要独立检索服务、过滤与管理能力的团队；Milvus 只在规模与运维能力同时成立时值得投入。这里不按绝对性能给冠军。

选型结论模板

写清场景、数据量级的估算方法、必须过滤字段、部署责任、备份恢复目标、已验证与未验证项。最后的选择应能解释“为什么这个系统的责任与团队匹配”，而不是“为什么它在某张图上更快”。

最小试用步骤：执行一次可退出的选型

先用 PostgreSQL 现有方案跑基线，再把同一数据导入一个专用候选；固定 embedding、过滤条件和硬件；执行新增、查询、更新、删除、备份、恢复六类动作；记录操作步骤与失败，不只记录延迟。只有基线确实不满足目标时，才继续评估更复杂的分布式候选。

这就是本文建议的可执行试用：第一轮最多比较基线和一个候选，不同时部署四套系统。试用结束时要么得到“基线已够用”，要么得到一个可复现缺口和候选改善证据；两者都没有就停止扩容评估。

结果解释边界

小样本本地测试只能淘汰明显不合适的方案，不能预测生产吞吐。厂商文档中的过滤、复制和高可用能力也需要按目标部署方式验证；托管服务与自托管版本可能拥有不同功能和责任，结论不能混用。

删除测试尤其重要：业务侧的“删除文档”要能够追到原文件、元数据、向量、缓存和备份保留策略。候选若只能新增和查询，却无法说明何时彻底不可检索，就不满足受控知识库的基本要求。

成本记录也不能只写机器规格。每个候选要同时记部署步骤、告警数量、备份时长、恢复人工操作和版本升级准备。专用数据库把查询延迟降低，却需要新增值班和迁移脚本时，收益必须覆盖这些持续责任。若团队没有对应负责人，托管方案或现有 PostgreSQL 往往比“技术上更快”的自托管集群更可靠。

最后由实际维护者签字确认运行手册，而不是让选型人替未来运维作承诺。无法确认告警、恢复和升级责任时，候选即使查询测试领先，也只保留为实验结果。