向量数据库真的要独立部署吗：pgvector、Qdrant、Milvus实战讨论

[admin]

向量数据库要不要独立部署，是很多 AI 应用团队迟早会遇到的架构争议。有人认为只要做 RAG、语义搜索或多模态检索，就应该上专门的向量数据库；也有人认为中小规模项目直接用 Postgres 加 pgvector 就够了，独立部署 Qdrant 或 Milvus 只会增加运维负担。两边都有真实经验，也都有过度简化的地方。问题不在于“向量数据库是不是先进”，而在于你的数据规模、查询模式、权限模型、备份要求、成本边界和团队运维能力到底支持哪种架构。

很多争论一开始就跑偏了。向量库不是知识库本身，也不是 RAG 的全部。它只负责在高维向量中做相似搜索，并配合过滤、索引、排序和元数据返回候选。真正的知识系统还需要原文、解析、分块、权限、引用、评测、同步和删除。把向量库独立部署，并不会自动解决召回质量和回答可信度；把向量塞进 Postgres，也不意味着系统就简单可靠。关键是先搞清楚向量层在整体系统里承担什么责任。

本篇用社区实践帖的方式讨论三个常见选择：Postgres + pgvector、Qdrant、Milvus。重点不做产品宣传，而是讲清楚什么时候“不要急着独立部署”，什么时候“独立向量库会明显更稳”，以及备份、权限、性能、成本和团队能力如何影响决策。读者可以把它当成一次架构评审前的准备材料。

一、先把问题问准：你要独立的是数据库，还是责任边界

很多团队说“要不要独立部署向量数据库”，实际问的是五个不同问题。第一，向量数据要不要和业务数据放在同一个数据库里。第二，向量查询要不要由专门引擎承担。第三，向量服务要不要独立扩缩容。第四，向量数据要不要有独立备份和恢复流程。第五，向量能力要不要成为平台级公共服务。五个问题的答案不一定相同。

一个小型知识库可能只有几万到几十万个片段，向量维度一千多，查询并发很低，元数据和权限都在 Postgres 里。这时把向量放在 pgvector 里，既减少系统数量，也方便事务一致性和备份。你不需要为了“架构像大厂”再部署一套独立向量库。

一个多租户 AI 平台可能有数千万到数十亿向量，多个应用共用检索能力，查询要做复杂过滤、混合检索、量化、分片、副本、批量导入和在线更新。此时把所有向量都塞进业务 Postgres，可能让主库压力、索引维护和扩容策略变得很痛苦。独立向量库的价值开始显现。

也有中间状态：业务数据仍在 Postgres，向量索引在 Qdrant 或 Milvus，原文和权限以业务数据库为准。向量库只存片段 ID、向量和必要过滤字段。查询时先按权限或元数据过滤，再做向量召回，最后回业务库取原文和引用。这种混合架构很常见，因为它承认向量库是检索索引，不把它当作唯一事实来源。

所以争论前先定义责任边界。Postgres 是否仍是权威数据源？向量库里是否保存完整文本？权限过滤在哪里发生？删除文档时谁负责清理向量？备份恢复时如何保证原文、元数据和向量一致？这些问题比“哪个向量库更快”更重要。

二、pgvector：不是玩具，适合从业务一致性开始

pgvector 是 PostgreSQL 的向量扩展，支持向量类型、相似度查询、HNSW、IVFFlat 等索引方式。它的最大优势不是极限性能，而是把向量和关系数据放在同一个成熟数据库体系里。对很多 AI 应用来说，这一点非常实用：文档、片段、租户、权限、版本、引用和向量可以一起建模，一起备份，一起用 SQL 查询。

pgvector 适合的第一类场景是早期 RAG 和企业知识库。数据量还没有大到需要专门集群，团队已经有 Postgres 运维经验，应用需要强元数据过滤和权限控制。比如一家公司给内部文档做知识库，只有几十万或几百万片段，用户按部门、项目和文档状态过滤。此时用 pgvector 能让系统结构更简单，也更容易和已有权限表关联。

第二类场景是事务一致性要求高。文档片段写入、元数据写入、权限变化和向量更新可以在同一个数据库事务或同一套变更流程里管理。虽然 embedding 计算本身通常是异步的，但片段状态、索引状态和可见性可以用关系表清楚表达。资料删除时，也可以通过外键、软删除和批处理保证派生向量不会长期遗留。

第三类场景是团队运维能力有限。多部署一个独立数据库，就多一套监控、备份、升级、安全、容量规划和故障恢复。Postgres 已经是很多团队最熟悉的数据库。把向量先放在 pgvector 里，可以让团队把精力用在资料解析、分块、召回评测和用户体验上，而不是先维护一个新集群。

但 pgvector 不是万能。向量规模变大后，索引构建、查询延迟、内存、存储膨胀和 VACUUM 压力都会成为问题。Postgres 主库同时承载业务事务和向量检索，可能相互影响。高并发近邻搜索会和普通业务查询争资源。若多个应用共享向量能力，schema、权限和查询模式会越来越复杂。此时继续坚持“一个 Postgres 管一切”，可能不是简单，而是把复杂度塞进主库。

pgvector 的另一个限制是向量检索能力边界。它可以满足大量普通相似搜索，但专用向量数据库在分布式扩展、集合管理、混合检索、量化、分片、HNSW 参数调优、快照和向量运维工具上通常更完整。如果系统已经进入大规模检索、低延迟、多租户或多应用共享阶段，就应该重新评估。

三、Qdrant：轻量专用向量库，工程手感比较直接

Qdrant 是专门为向量相似搜索设计的数据库，支持 collection、payload、过滤、HNSW 索引、量化、快照、分布式部署和多种客户端。它在社区里的一个常见评价是“比 Milvus 轻一些，比 pgvector 更像专用检索服务”。这个评价不必绝对化，但确实能概括很多中型团队的体验：当 pgvector 开始吃力，而团队还不想上很重的分布式系统时，Qdrant 是常被考虑的选择。

Qdrant 的优势之一是过滤和 payload 模型直观。向量点可以带 payload，查询时可以按租户、文档类型、标签、时间、权限字段等过滤。对 RAG 来说，这很重要，因为真实检索很少是“全库找最相似”。用户往往只在某个租户、某个项目、某个知识库、某个时间范围和某种资料类型里搜索。过滤能力直接影响召回质量和权限安全。

第二个优势是部署形态相对清楚。小规模可以单节点运行，后续再考虑分片、复制和集群。快照功能可以用于集合级备份和迁移。官方文档也覆盖了索引、优化器、存储、量化、快照、认证和访问控制等生产要素。对不想把向量压力放在 Postgres 主库上的团队，Qdrant 能把检索负载独立出来。

第三个优势是适合多模态检索。图片向量、文本向量、文档页面向量、视频片段向量都可以作为点存储，再用 payload 记录来源、时间、页码、模态和权限。Qdrant 文档中也提到多模态查询和混合查询相关能力。虽然跨模态检索的质量主要取决于 embedding 和索引单元设计，但专用向量库更容易承载多种 collection 和不同索引策略。

Qdrant 的成本也要算清楚。它虽然比大型分布式平台轻，但仍然是一套独立服务。你要监控磁盘、内存、查询延迟、索引构建、快照、备份恢复、版本升级和访问控制。你还要决定业务库和 Qdrant 之间的一致性策略。文档删除了，向量是否同步删除？权限收紧了，payload 是否更新？Qdrant 快照恢复到某个时间点后，Postgres 数据是否也能恢复到一致时间点？

Qdrant 适合的典型场景是：向量规模已经让 pgvector 查询或索引维护压力明显；团队需要更丰富的向量过滤和索引控制；RAG 或多模态检索是应用核心路径；但系统规模还没有复杂到必须上重型分布式向量平台。它也适合把向量检索做成一个独立能力，供多个应用调用。

四、Milvus：大规模和分布式能力强，但运维心智更重

Milvus 是面向大规模向量检索的开源向量数据库，文档中强调 collection、schema、index、segment、query node、data node、coordination、object storage、message queue 等组件和概念。它适合处理更大规模、更高吞吐、更复杂分布式场景，但也意味着更多运维心智。选择 Milvus 通常不是为了“更专业”这四个字，而是因为规模和架构需求真的到了那一步。

Milvus 的优势在大规模检索和分布式架构。海量向量、多 collection、多索引类型、分片、扩展、批量导入、冷热数据、云原生部署，这些场景更接近 Milvus 的设计目标。对于大型图片检索、推荐、风控特征检索、多租户平台、海量文档向量和企业级 AI 基础设施，Milvus 的能力边界比轻量方案更宽。

Milvus 的索引选择也比较丰富。不同场景可以选择 IVF、HNSW、DiskANN、压缩或量化相关方案，配合距离度量和搜索参数调节召回率、延迟和资源消耗。大规模向量检索一定会进入这些权衡：索引越精确，资源越高；索引越压缩，召回可能下降；查询越快，构建和内存可能更贵。Milvus 给了更多可调空间，但也要求团队真正理解这些参数。

Milvus 的代价是系统复杂度。你要理解它的部署组件、元数据服务、对象存储、消息队列、数据节点、查询节点、索引节点、负载均衡、备份工具、RBAC、升级路径和容量规划。若团队只有一个后端工程师兼职运维，数据量也不大，上 Milvus 很可能得不偿失。不是 Milvus 不好，而是问题不够大时，复杂工具会把精力从产品质量上拿走。

备份和恢复是 Milvus 选型时必须提前看的点。Milvus 有专门的备份工具和相关文档，适合更严肃的数据保护流程。但你仍要处理业务数据库、对象存储和 Milvus 之间的一致性。如果原文在对象存储，元数据在 Postgres，向量在 Milvus，三者恢复到不同时间点，知识库会出现引用缺失、向量孤儿或权限错配。

Milvus 适合的典型场景是：向量量级很大，单机或单库方案已经明显不够；查询吞吐和延迟有明确指标；团队能投入专门运维；向量检索是平台基础设施；需要分布式扩展、复杂索引和企业级治理。反过来，如果你只是给几万份文档做内部问答，Milvus 很可能不是第一步。

五、独立部署的真实收益

独立向量库的第一项收益是资源隔离。向量检索通常是 CPU、内存和磁盘 IO 都比较敏感的工作。HNSW 索引需要内存，批量导入需要写入和构建索引，检索高峰会拉高延迟。如果这些负载都压在业务 Postgres 主库上，普通业务读写可能被拖慢。独立部署后，向量检索可以单独扩容、限流和压测。

第二项收益是索引能力。专用向量库通常提供更丰富的索引、量化、payload 过滤、集合管理和优化器。pgvector 能满足很多场景，但在大规模、多集合、多索引策略和多租户隔离上，专用引擎会更自然。特别是多模态检索中，不同模态可能需要不同维度、不同距离度量和不同过滤字段，独立向量库更容易管理。

第三项收益是服务边界清楚。当多个应用都需要语义检索时，独立向量服务可以成为平台能力。应用不必直接操作数据库表，而是通过检索 API 提交查询、过滤条件和召回数量。平台可以统一做限流、审计、索引版本、召回评测和模型升级。这样比每个应用各自建表、各自调索引更可控。

第四项收益是扩展路线更明确。向量数据增长很快时，独立服务更容易做分片、副本、冷热分层和专用硬件优化。业务数据库的扩容往往受事务和关系模型限制，向量库则可以围绕检索负载优化。对高并发搜索、图片检索和推荐类场景，这一点很关键。

第五项收益是故障影响可控。向量服务出问题时，业务系统可以降级为全文检索、缓存结果或提示稍后重试；业务数据库不一定受影响。反过来，如果所有东西都在一个 Postgres 主库里，向量索引异常、慢查询或磁盘膨胀可能直接影响核心业务。资源隔离不是形式，而是故障边界。

但这些收益只有在系统规模和团队流程跟上时才成立。独立部署不是免费午餐。若没有监控、备份、权限同步和一致性设计，独立向量库只会多一个出事故的地方。

六、不独立部署的真实收益

不独立部署最大的收益是简单。一个数据库、一套备份、一套权限、一套事务、一套监控，对小团队非常重要。很多 AI 产品失败不是因为向量库不够强，而是资料解析差、分块乱、引用不准、评测缺失和用户体验糟。早期把技术栈压简单，反而更容易把核心链路打磨好。

第二个收益是一致性。业务数据、文档元数据、片段和向量在同一数据库里，删除、权限变化、版本切换和状态管理更容易做对。尤其是知识库，向量只是派生索引，必须跟随原文和权限变化。同库设计可以减少跨系统同步错误。

第三个收益是权限自然。PostgreSQL 支持成熟的角色、权限、行级安全策略和 SQL 过滤。若团队已经把租户、项目、用户和文档权限建在 Postgres 里，pgvector 查询可以直接与权限表关联。这样比把权限字段复制到向量库 payload，再维护同步，要少很多风险。

第四个收益是备份恢复直接。PostgreSQL 官方备份和恢复体系成熟，pg_dump、物理备份、WAL、PITR 都有清晰路线。向量和元数据在同一个数据库时，恢复一致性更容易解释。虽然大向量索引会增加备份体积和恢复时间，但至少责任边界清楚。

第五个收益是开发效率。SQL 调试、迁移、数据修正、报表统计和权限排查都能在一个体系里完成。开发人员不需要在两个数据库之间来回查 ID、对时间点、修孤儿数据。对很多业务型 AI 应用来说，开发效率比极限检索性能更重要。

不独立部署的代价也很真实。随着向量数据增长，Postgres 可能变成瓶颈；向量查询和业务事务争资源；索引重建影响主库；多应用共享变得混乱；不同模态和不同模型维度难以管理。简单架构有红线，过了红线就会变成隐性复杂。

七、性能判断：别只问能存多少向量

向量库性能不能只看“能存多少条向量”。真正要看的是查询延迟、吞吐、召回率、过滤选择性、写入速度、索引构建时间、更新频率、内存占用、磁盘体积和恢复时间。不同应用的瓶颈完全不同。一个离线知识库可以接受几百毫秒检索，一个实时推荐系统可能要求几十毫秒；一个内部搜索一天几千次查询，一个用户产品可能每秒几百次查询。

向量维度影响存储和计算。常见 embedding 可能是几百到几千维。维度越高，单条向量越大，距离计算越贵，索引占用越高。若每个片段还保存多种 embedding，例如中文文本向量、英文向量、图片向量、页面向量，存储会成倍增加。选型时不要只按文档数量估算，要按片段数、维度、精度、索引倍率和副本数估算。

过滤选择性很关键。RAG 查询通常先按租户、知识库、文档状态、权限、语言和时间过滤，再做向量搜索。如果过滤条件很强，候选空间小，pgvector 可能足够快；如果过滤条件复杂且数据量大，专用向量库的 payload index 和过滤执行计划可能更有优势。反过来，如果每次都全库搜，独立向量库也会承受很大压力。

召回率和延迟是 trade-off。HNSW、IVFFlat、量化和其他近似索引都需要调参数。更高召回通常意味着更多内存、更长查询或更慢构建。很多团队只看默认参数，结果要么慢，要么漏召回。生产系统应建立检索评测集，调索引参数时同时看 top-k 命中、延迟和成本。

更新模式也影响选型。文档知识库通常是增量写入和少量删除；聊天记忆可能频繁新增；推荐特征可能批量刷新；图片库可能大量导入；代码库每次提交更新部分文件。pgvector、Qdrant、Milvus 对写入、索引构建和 compaction 的表现不同。选型前要模拟真实写入和查询混合，而不是只跑静态 benchmark。

还要关注尾延迟。平均延迟好看不够，P95、P99 才决定用户体验。向量查询在索引重建、批量导入、磁盘抖动、过滤条件异常和缓存失效时可能出现尾延迟。独立部署可以用资源隔离和限流控制尾延迟，但也需要监控和容量规划。

八、权限：向量检索不能绕过业务安全

权限是向量库选型里最容易被低估的问题。用户无权访问的资料，不应该因为向量相似就被召回。正确做法是在检索前或检索过程中应用权限过滤，让模型上下文只包含当前用户有权看的片段。不能先全库召回，再让模型自己判断哪些内容不能说。

pgvector 的优势是能和业务权限表直接 join。比如文档片段表包含 document_id，权限表记录用户和文档的关系，查询时先过滤用户可访问文档，再做向量排序。PostgreSQL 的行级安全策略也可以用于多租户隔离。缺点是复杂权限 join 可能影响向量查询性能，需要设计索引和查询计划。

Qdrant 的权限通常通过 payload 过滤、API key、访问控制和应用层授权组合实现。向量点带租户、知识库、项目、文档状态等字段，查询时附带 filter。更细的用户级权限如果频繁变化，复制到 payload 可能很麻烦。很多系统会只把粗粒度租户和知识库放到向量库，细粒度权限在业务层预过滤或二次校验。

Milvus 也提供用户、角色和权限相关能力，但业务权限仍然不能完全交给数据库内置 RBAC。Milvus 的 RBAC 管的是谁能操作 collection、数据库和对象，不等同于某个终端用户是否能读取某份合同。多租户和文档级权限仍然需要业务元数据、过滤字段和应用层逻辑配合。

权限变化是最大难点。用户加入项目、离开团队、文档从公开改为私密、合同过期、客户要求删除资料，这些变化要影响检索可见性。如果权限字段复制到独立向量库，就要保证同步及时。若同步延迟，可能短时间泄漏；若同步失败，可能长期错配。高安全场景更适合在业务数据库中做权威权限判断，向量库只做可控范围内的候选召回。

还有一种常见风险是缓存。检索结果、重排结果和模型回答都可能缓存。权限收紧后，缓存也要失效。独立向量库不会自动帮你处理应用缓存和模型上下文。安全边界必须贯穿向量库、业务库、缓存、日志和回答输出。

九、备份和恢复：向量是派生数据，但不能随便丢

有人说向量都是 embedding 算出来的，丢了可以重建，所以不用认真备份。这个说法只对一半。向量确实是派生数据，但重建需要原文、解析结果、分块策略、embedding 模型、模型版本、任务队列和时间。若数据量很大，重建可能需要几小时、几天甚至更久，还会消耗大量模型费用。生产系统不能把“理论上可重建”当作恢复方案。

pgvector 的备份跟随 PostgreSQL。优点是元数据和向量可以一起备份，一起做时间点恢复。缺点是备份体积会变大，恢复时间也会增加。大型 HNSW 或 IVFFlat 索引可能占用不少存储。你需要决定是否备份索引，还是恢复后重建索引。这个选择会影响恢复时间目标和存储成本。

Qdrant 提供 snapshots，用于 collection 或整个存储的备份和迁移。快照很方便，但也要和业务数据库的备份时间对齐。如果 Postgres 恢复到 10:00，Qdrant 恢复到 10:15，可能出现向量指向不存在的片段；反过来，Postgres 有新文档，Qdrant 没有对应向量。最稳的做法是用索引状态表记录每个片段是否已索引，并在恢复后跑一致性检查和补偿任务。

Milvus 有专门的备份工具和对象存储相关流程，更适合大规模集群。但复杂系统里的恢复演练更重要。Milvus、对象存储、消息队列、元数据库和业务库之间都可能有状态关系。只看文档说支持备份不够，团队要实际演练：删一批向量如何恢复，集群损坏如何恢复，业务库回滚后如何让向量索引同步回滚。

备份策略还要区分原文、解析结果、向量和索引。原文最重要，必须可靠保存；解析结果可以重建，但保存后能节省时间；向量可以重算，但成本可能高；索引可以重建，但耗时可能长。不同层的备份频率、保留期限和恢复优先级可以不同。不要把所有东西混成一个“备份数据库”的问题。

恢复后要做校验。检查向量点数量、孤儿向量、缺失向量、权限字段、文档状态、索引版本和召回样本。很多事故不是恢复失败，而是恢复后系统表面可用，实际引用错乱或权限错配。知识库和检索系统应有恢复后健康检查脚本或任务，但这不等于让读者看到内部脚本名，面向用户的状态应保持清晰。

十、成本：数据库成本只是总成本的一部分

向量系统的成本包括存储、内存、CPU、网络、备份、监控、运维、人力、模型调用和故障恢复。只比较“Qdrant 机器多少钱”或“Milvus 集群多少钱”是不完整的。pgvector 看似省一套服务，但可能增加 Postgres 主库规格和备份体积；独立向量库看似多一套服务，但可能保护业务主库并降低性能风险。

存储成本要按向量数、维度、精度、索引倍率和副本数算。比如一千万个 1536 维 float32 向量，原始向量就已经是数十 GB 级别，再加索引、payload、元数据、WAL、备份和副本，实际占用会明显更高。若每个片段还保留原文、OCR、摘要和多种 embedding，成本会继续上升。

内存成本通常比磁盘更敏感。HNSW 索引为了低延迟往往需要较多内存。Qdrant、Milvus 和 pgvector 都需要根据索引方式和查询目标规划内存。若机器内存不足，查询可能退化，尾延迟上升。磁盘型索引和量化可以降低资源，但可能影响召回或延迟。

模型成本也要算入向量库决策。换 embedding 模型、调整分块策略、重建多模态索引，都需要重新生成向量。若向量库设计导致频繁全量重建，模型费用会超过数据库费用。保留 embedding 模型版本、索引版本和增量更新能力，可以减少无谓重算。

人力成本最容易被忽略。Milvus 集群、Qdrant 集群和 Postgres 主库扩展都需要人维护。小团队如果没有专门运维，选轻方案更稳；大团队如果有平台工程能力，独立向量服务可以降低长期混乱。架构选择不只看技术上能不能，还要看团队能不能长期负责。

故障成本也要考虑。向量检索如果是核心路径，停机可能影响用户搜索、客服回答、推荐结果或 Agent 决策。独立部署可以做降级和隔离，但也多一个故障点。不独立部署少一个服务，但可能把向量故障拖到主库。成本判断要结合故障影响，而不是只看月账单。

十一、数据一致性：双写不是小问题

一旦向量库独立，业务库和向量库之间就会出现同步问题。常见流程是文档上传到对象存储，元数据写入 Postgres，后台解析生成片段，调用 embedding 模型生成向量，再写入 Qdrant 或 Milvus。任何一步失败，都可能出现状态不一致。比如文档显示已入库，但向量没写成功；向量写成功，但元数据事务回滚；权限更新了，但 payload 没更新；文档删除了，但向量仍可召回。

解决一致性问题的核心是状态机。文档和片段要有处理状态：待解析、解析中、解析失败、待 embedding、索引中、索引完成、索引失败、已删除。应用查询时只使用索引完成且可见的片段。失败任务要能重试，删除任务要能补偿，状态变更要可审计。不要让向量库写入变成一个没有记录的后台副作用。

Outbox 模式或任务队列常用于同步。业务库先记录待索引事件，再由 worker 消费并写入向量库。写入成功后更新索引状态。若 worker 崩溃，事件还在；若向量库不可用，任务可重试。这个模式比在业务请求里直接双写两个数据库更可靠。

删除要特别严肃。资料删除、权限撤销和客户数据清理，不能只删业务库记录。向量库、全文索引、缓存、摘要和评测样本都可能保留派生内容。应有统一的数据生命周期任务，确保派生数据不可召回。对于合规要求高的系统，还要区分软删除、审计保留和硬删除。

版本也要管理。分块策略、embedding 模型和索引参数都会变化。一个片段可能有多个向量版本。上线新 embedding 时，不一定要立刻覆盖旧索引，可以并行构建新 collection 或新列，评测通过后切换。没有版本管理，系统很难解释为什么同一个问题昨天能召回，今天召回不到。

十二、RAG 场景里的选择建议

内部知识库初期，优先考虑 pgvector。原因很简单：元数据、权限、文档状态和向量放在同一个 Postgres 里，系统更容易做对。数据量在几十万到几百万片段、查询并发不高、团队已有 Postgres 经验时，pgvector 通常足够。此阶段更该投入到解析、分块、评测和引用，而不是过早上复杂向量集群。

当查询变慢、向量表膨胀、主库压力明显、多个应用抢同一套检索能力时，可以考虑 Qdrant。它能把检索负载独立出来，payload 过滤和 collection 管理更适合向量场景。迁移时不要一次把业务事实搬过去，只把向量、片段 ID 和必要过滤字段放到 Qdrant，Postgres 仍保存权威元数据和原文。

当数据量非常大、查询吞吐高、需要分布式扩展和多团队平台化时，再考虑 Milvus。Milvus 不是小项目的默认答案，它更像面向大规模向量基础设施的工具。若没有专门运维和明确性能目标，先上 Milvus 可能把团队拖入集群维护。

有些 RAG 场景其实不该从向量库开始优化。如果召回不准，先看分块是否合理、embedding 是否适合中文和领域文本、是否有全文检索、是否做重排、是否过滤了错误资料、问题是否改写过、引用是否来自权威文档。很多时候，换向量库不能解决这些问题。

还要记住混合检索。中文知识库里，专有名词、错误码、条款编号、接口名、产品型号、文件路径和人名非常常见。纯向量检索容易漏掉精确词。Postgres 全文检索、Elasticsearch、OpenSearch 或其他全文索引可以和向量库结合。架构上不要把“向量数据库”误解成“唯一检索系统”。

十三、多模态检索里的选择建议

多模态检索会放大向量库选择问题。图片、视频片段、PDF 页面、OCR 区块、语音片段和文本段落可能都有自己的 embedding。维度不同、距离度量不同、更新频率不同，索引单元也不同。一个简单知识库可能只有一张 chunk 表，多模态系统可能要有图片 collection、页面 collection、视频片段 collection、文本 chunk collection 和跨模态映射表。

pgvector 仍然可以作为起点。比如一个文档理解系统，只需要按页面和文本片段做检索，数据量不大，Postgres + pgvector 可以同时保存页面元数据、OCR、文档权限和页面向量。这样引用页码、权限过滤和恢复都简单。

Qdrant 很适合中等规模多模态索引。不同 collection 可以管理不同模态，payload 记录页面、时间戳、区域、租户和文档 ID。用户用文字检索图片或页面时，系统可以先查对应 collection，再回业务库取原文和引用。若使用多向量或混合检索，也更容易在专用向量服务里组织。

Milvus 适合大规模图片检索、视频检索和推荐检索。比如海量商品图、素材库、安防视频片段、工业缺陷图、内容平台推荐特征等，向量量级和吞吐都可能远超普通文档 RAG。此时分布式扩展、批量导入、索引构建和资源隔离的重要性会超过开发简单性。

多模态场景还要关注原始媒体存储。向量库不应该保存完整视频、高清图片或 PDF 原文。对象存储保存原始媒体，业务库保存元数据和权限，向量库保存索引。引用时通过业务服务生成可授权访问的链接或预览。不要把向量库变成媒体仓库，也不要让向量点里塞大量不可控文本和图片数据。

十四、迁移路线：从 pgvector 到独立向量库

很多团队不是一开始就选对，而是从简单方案长到复杂方案。比较稳的路线是先用 pgvector 建立正确的数据模型：documents、document_versions、chunks、embeddings、index_jobs、permissions、citations。即使未来迁移到 Qdrant 或 Milvus，这些业务表仍然有价值。

第二步，把向量访问封装成检索服务或 repository，而不是让业务代码到处写 SQL。应用只调用 search(query, filters, top_k) 这样的能力，不关心底层是 pgvector 还是 Qdrant。这样迁移时影响范围小。封装不是为了过度设计，而是为了避免向量库选择渗透到所有业务逻辑。

第三步，增加索引版本。每条 embedding 记录模型、维度、距离度量、分块版本和创建时间。迁移到独立向量库时，可以把同一批片段写入新 collection，跑双读评测，对比召回结果和延迟。不要直接切换生产查询，尤其是知识库核心路径。

第四步，做双写和回放。新片段同时写 pgvector 和独立向量库，旧片段通过后台任务回填。查询可以先仍走旧库，同时记录新库召回结果用于对比。评测通过后再灰度切换部分租户或部分知识库。切换失败时能回退到旧库。

第五步，明确最终责任。迁移完成后，pgvector 是否还保留向量？是作为回滚保留，还是只保留业务元数据？独立向量库的备份由谁负责？权限字段如何同步？索引失败谁告警？这些都要写进运维流程。否则迁移完成只是技术上能跑，长期仍然混乱。

十五、选型决策表

如果你的向量数据小于几百万片段，查询并发低，团队已有 Postgres，权限和元数据复杂，优先 pgvector。它不是退而求其次，而是用最少组件把业务正确性做好。

如果你的向量数据增长到千万级附近，查询延迟开始影响体验，Postgres 主库压力明显，或者多个应用需要共享检索能力，可以评估 Qdrant。它通常是从单库方案走向专用向量服务的务实选择。

如果你的向量数据继续扩大，查询吞吐高，分布式扩展是硬需求，有专门平台团队，并且向量检索本身是核心基础设施，可以评估 Milvus。此时要把备份、监控、升级和容量规划当作项目的一部分，而不是部署后再补。

如果你的问题主要是召回不准，不要先换数据库。先检查分块、embedding、全文检索、重排、问题改写、资料质量、元数据过滤和评测集。向量数据库只能提高检索执行能力，不能替你理解业务资料。

如果你的问题主要是权限复杂，优先保证权威权限在业务系统里可验证。独立向量库可以做粗粒度过滤，但不要让 payload 成为唯一权限来源，尤其是权限变化频繁的企业系统。

如果你的问题主要是成本，先算全成本。包括数据库机器、备份、运维、人力、embedding 重算、故障影响和主库风险。很多时候最便宜的方案不是机器最少的方案，而是团队能稳定维护、出错后能快速恢复的方案。

十六、常见误区

第一个误区是以为上了专用向量库，RAG 质量就会变好。召回质量主要取决于资料治理、分块、embedding、混合检索、重排和评测。向量库只是执行层。

第二个误区是把向量库当权威数据源。原文、文档版本、权限和引用应该在业务系统或对象存储中可靠保存。向量库里最好只放索引所需数据和必要过滤字段。

第三个误区是小项目过早上重集群。Milvus、分布式 Qdrant 或其他复杂方案需要运维能力。没有规模压力时，复杂度会吞掉产品迭代时间。

第四个误区是一直不拆。数据和并发上来后，pgvector 放在主库里可能影响业务事务、备份和扩容。简单方案要有迁移出口，不能靠侥幸硬撑。

第五个误区是忽视权限同步。独立向量库中的 payload 不是天然安全边界。权限变化、文档删除和租户隔离必须有同步和校验。

第六个误区是没有恢复演练。备份存在不等于能恢复。恢复后还要检查向量和原文是否一致、引用是否可打开、权限是否正确、召回是否正常。

第七个误区是只看平均延迟。P95、P99、批量导入时延迟、索引重建时延迟、过滤条件异常时延迟，才是真实用户会遇到的问题。

第八个误区是把全文检索丢掉。错误码、条款号、函数名、产品型号和人名经常需要精确匹配。向量检索应该和全文检索配合，而不是替代一切。

十七、检查清单

• 向量库是否只是索引层，原文、版本、权限和引用是否另有权威来源？
• 当前片段数量、向量维度、索引倍率、副本数和未来一年增长是否估算过？
• 查询是否需要复杂过滤、租户隔离、文档状态、时间范围和权限约束？
• 当前瓶颈是检索执行性能，还是分块、embedding、重排和资料质量？
• 是否记录 embedding 模型版本、分块版本、索引版本和距离度量？
• 文档新增、修改、删除、权限变化后，向量索引是否能及时同步？
• 是否有索引任务状态机、失败重试和补偿机制？
• 是否能恢复业务库、对象存储和向量库到一致状态？
• 是否演练过向量库恢复、回滚、重建索引和孤儿向量清理？
• 是否有 P95、P99、召回率、索引构建时间、存储和成本监控？
• 是否为高风险资料设置检索前权限过滤，而不是生成后遮掩？
• 是否保留全文检索或结构化查询能力，避免纯向量搜索覆盖所有任务？

十八、结论：先让系统正确，再让检索独立

向量数据库要不要独立部署，没有统一答案。小团队、早期产品、内部知识库、权限和元数据强绑定的场景，pgvector 往往是更稳的起点。它让你先把资料模型、权限、引用、同步和评测做对。中等规模、检索压力明显、多应用共享和多模态索引增多时，Qdrant 这类专用向量库能提供更清楚的资源隔离和检索能力。大规模、高吞吐、分布式平台和复杂索引场景，Milvus 更值得评估，但必须配套运维能力。

最重要的判断标准不是工具名，而是责任边界。向量库负责相似搜索，不负责替你治理资料；独立部署负责资源和能力隔离，不自动带来质量；不独立部署降低复杂度，但要警惕主库压力和迁移难度。一个成熟团队应该能回答：数据在哪里权威保存，权限在哪里判断，索引如何同步，故障如何恢复，成本如何归因，质量如何评测。能回答这些问题，选 pgvector、Qdrant 还是 Milvus，才会变成工程决策，而不是信仰争论。

参考资料

• pgvector GitHub 官方项目：https://github.com/pgvector/pgvector
• PostgreSQL Row Security Policies 文档：https://www.postgresql.org/docs/current/ddl-rowsecurity.html
• PostgreSQL Backup and Restore 文档：https://www.postgresql.org/docs/current/backup.html
• Qdrant 官方文档：https://qdrant.tech/documentation/
• Qdrant Filtering 文档：https://qdrant.tech/documentation/concepts/filtering/
• Qdrant Snapshots 文档：https://qdrant.tech/documentation/concepts/snapshots/
• Qdrant Quantization 文档：https://qdrant.tech/documentation/guides/quantization/
• Milvus 官方文档：https://milvus.io/docs
• Milvus Index Vector Fields 文档：https://milvus.io/docs/index-vector-fields.md
• Milvus RBAC 文档：https://milvus.io/docs/rbac.md
• Milvus Backup 文档：https://milvus.io/docs/milvus_backup_overview.md
• OpenAI Vector Stores and File Search 文档：https://platform.openai.com/docs/guides/tools-file-search