在当下RAG知识库、智能问答、语义检索项目遍地开花的技术环境下，向量数据库早已不是小众技术选型，而是AI应用落地的核心基础设施。但凡做语义召回、智能问答、文本相似度匹配的项目，几乎都绕不开向量数据库的搭建与运维。
打开各大技术社区，关于主流向量数据库Milvus和Qdrant的对比测评数不胜数，但我翻看了大量内容后发现一个普遍问题，绝大多数测评都仅仅停留在本地搭建Demo、跑简单测试用例的层面，靠着几组基础数据就武断判定孰优孰劣。这种脱离生产环境的结论，对于真正要落地项目、要扛真实业务流量的研发人员来说，参考价值极低，甚至会误导技术选型。
作为一线软件开发从业者，我今年全程主导了公司内部知识库问答系统的搭建工作，核心的向量检索模块，我先后完整落地了Milvus和Qdrant两套架构，Milvus在线上稳定运行大半年，Qdrant也经历了数月真实业务流量的打磨。不同于纸上谈兵的测评，我踩过了两款数据库生产环境的运维坑、性能瓶颈、适配短板，也摸清了它们在不同业务场景下的真实特性。
本文不做非黑即白的优劣评判，没有绝对完美的向量数据库，只有适配场景不同的技术选型。我将结合千万级数据体量、日均数万新增数据的真实业务场景，实打实拆解两款数据库的落地体验、性能差异、运维成本，同时分享经过实战验证的选型逻辑，帮大家避开Demo测评带来的认知误区。
一、先讲清楚我的核心业务场景，所有对比均基于真实落地环境
任何技术选型的对比，脱离业务场景都是空谈。为了让所有测评结论、优缺点分析更有参考性，我先完整介绍我们公司的落地场景，这也是本文所有对比结论的核心依据。
我们搭建的是企业内部专属知识库问答系统，核心数据源为公司内部规章制度、业务政策文档、各产品线FAQ、历史业务工单等私密业务数据。截至目前，系统内有效向量数据总量达到1200万条，且业务处于持续迭代状态，每天会新增数万条全新文档向量数据，数据增量稳定且长期持续。
基于业务使用需求，我们对向量检索模块设定了两个核心刚需，也是考验两款数据库能力的关键指标。第一个是基础语义召回需求，用户在前端输入业务问题后，系统需要通过向量检索，快速召回Top20的相关文档片段，为后续大模型问答生成提供素材，对检索速度、准确率有硬性要求。第二个是进阶过滤检索需求，这个需求是后期业务迭代新增的，也是拉开两款数据库使用体验差距的关键，系统需要支持按照业务线、文档类型、发布时间范围等多维度条件筛选数据，在筛选后的精准数据池中再完成向量检索，实现精细化语义召回。
正是这两个一简一繁的业务需求，让我彻底看清了Milvus和Qdrant在生产环境中的真实定位。单纯的基础向量检索场景，两款数据库都能满足需求，但一旦叠加复杂元数据过滤、高频数据更新、长期稳定运维等生产级诉求，二者的架构设计短板与核心优势就会彻底暴露。
二、Milvus生产落地体验，全能性能背后是沉重的运维负担
在项目初期，我们优先选择了Milvus作为核心向量数据库，这也是国内AI项目中普及率最高的向量数据库。当初选型Milvus，核心是看中它两大核心优势，一是公开测评中亮眼的检索性能，二是成熟完善的技术生态，能够与Spring AI等主流AI开发框架实现官方适配，开发接入成本极低。经过大半年的生产环境打磨，我确实感受到了Milvus的强大能力，但也深刻体会到了它架构设计带来的固有痛点。
2.1 生产环境下的核心优势，大数据场景无可替代
Milvus采用经典的存算分离架构，这一架构设计让它天生适配大数据量、高并发、可横向扩展的生产场景，在我们千万级数据体量的业务中，优势体现得淋漓尽致。
首先是极致的检索性能，我们基于1200万条业务向量数据，采用HNSW索引模式搭建检索服务，在日常业务平稳运行状态下，单条查询延迟能够稳定控制在10ms以内，响应速度完全满足用户无感交互的需求。即便在工作日业务高峰期，平台每秒承载数百次用户查询请求，整个集群依然能保持稳定输出，不会出现延迟飙升、请求超时的问题，高并发承载能力完全经得起生产流量考验。
其次是丰富多元的索引类型，适配全场景数据检索需求。Milvus原生支持HNSW、IVF、DISKANN等多种主流向量索引，不同索引能够适配不同的业务工况。日常中小体量数据检索，HNSW索引能够兼顾速度与精度；当数据量持续暴涨、服务器内存资源紧张时，我们可以无缝切换为DISKANN磁盘索引，将数据存储压力转移至磁盘，极大降低内存占用，完美解决大数据量场景下的资源瓶颈。相比之下，很多轻量向量数据库的索引模式单一，无法适配复杂的资源约束场景。
最后是灵活的水平扩展能力，适配业务长期迭代。存算分离的架构设计，让Milvus的算力和存储资源可以独立扩容，互不干扰。随着我们公司业务扩张，知识库文档数据持续增长，我们无需重构架构、无需迁移数据，仅需要简单新增集群节点，就能完成算力和存储的扩容，轻松支撑亿级数据的落地，这也是中小型向量数据库无法比拟的核心优势。
2.2 生产踩坑汇总，运维复杂度是最大硬伤
如果说性能和扩展性是Milvus的加分项，那运维复杂度就是它最大的减分项，也是很多中小团队落地后后悔选型的核心原因。很多Demo测评只会介绍Milvus的性能优势，却不会提及生产环境中多组件依赖带来的连锁问题。
Milvus并非单一服务组件，完整的生产集群需要依赖etcd、MinIO、Pulsar三大核心组件协同工作，其中etcd负责存储和管理集群元数据，MinIO承担对象存储任务，Pulsar作为消息队列处理数据同步与异步任务。这就意味着，我们搭建一套完整的Milvus生产环境，不仅要运维Milvus本身，还要同时维护三套独立的中间件服务。
生产环境的稳定性风险也随之翻倍，整套集群的可用性取决于所有组件的稳定性，任意一个组件出现故障，都会导致整个Milvus检索服务瘫痪。我们线上就真实遇到过这类事故，一次Pulsar消息队列异常宕机，没有任何报错预警，直接导致整个Milvus集群无法提供检索服务，业务全面中断，我们排查了近两个小时，才定位到是消息队列组件的问题，整个排查过程繁琐且耗时。
同时，Milvus存在明显的场景局限性，小数据量场景下完全大材小用。如果业务数据仅有几十万条，搭建全套的Milvus集群完全是资源浪费，多组件的部署架构会占用大量服务器资源，且复杂的架构设计无法发挥性能优势，属于典型的杀鸡用牛刀。
最影响业务迭代体验的，是它的元数据过滤能力短板。我们业务需要的先过滤、后检索的精细化召回需求，在Milvus中实现难度极大。Milvus的向量检索和标量过滤是相互分离的两个步骤，配置独立、逻辑割裂，想要实现多条件组合过滤检索，需要编写极其繁琐的配置表达式，调试过程复杂，排错成本极高，极大降低了开发迭代效率。而且它的过滤逻辑是先完成全量向量检索，再做二次过滤，多了一层冗余工序，在复杂过滤场景下，性能损耗非常明显。
三、Qdrant落地实战，轻量高效适配中小团队绝大多数场景
在完成内部知识库系统搭建后，我们承接了一个客户侧的轻量化文档问答项目，基于过往Milvus的运维痛点，我们这次直接尝试了Qdrant向量数据库。经过数月生产落地，我最大的感受就是，Qdrant是一款极度贴合中小团队、轻量化业务场景的工具，它舍弃了部分极致的大数据扩展能力，换来了极简的部署运维、极致易用的过滤能力，在中小型业务场景下，体验远超Milvus。
3.1 核心优势，低运维成本+超强过滤能力直击业务痛点
Qdrant最核心的亮点就是极简的部署运维模式，彻底颠覆了Milvus多组件依赖的繁琐架构。它支持单容器一键部署，整套服务仅需一个Docker容器即可完整运行，无需额外搭建etcd、对象存储、消息队列等配套组件，部署流程简单到新手研发也能快速上手。
这种轻量化架构带来的优势在生产环境中被无限放大，首先是服务器资源占用更低，同等数据量、同等机器配置下，Qdrant的内存占用远低于Milvus。其次是运维成本几乎可以忽略不计，服务升级、重启、迁移都十分便捷，没有复杂的集群配置、组件联动问题，不需要专人专职运维，极大节省了中小团队的人力成本和服务器资源成本。
而Qdrant真正的杀手锏，是原生的向量加元数据一体化过滤能力，这也是它区别于Milvus的核心竞争力。Qdrant在架构设计之初，就将向量数据和业务元数据深度绑定，检索和过滤逻辑原生融合，无需拆分步骤、无需复杂配置，仅通过一个API接口就能完成多条件过滤加向量检索的全流程操作，完美适配我们的精细化召回业务需求。
给大家贴一段我们生产环境中实际使用的代码，直观感受它的简洁高效：
Filter filter = Filter.newBuilder()
.addMust(FieldCondition.newBuilder()
.setKey("biz_line")
.setMatch(Match.newBuilder().setKeyword("售后").build())
.build())
.addMust(FieldCondition.newBuilder()
.setKey("doc_type")
.setMatch(Match.newBuilder().setKeyword("政策").build())
.build())
.build();
SearchPoints search = SearchPoints.newBuilder()
.setCollectionName("knowledge")
.addAllVector(queryVector)
.setFilter(filter)
.setLimit(20)
.setWithPayload(WithPayloadSelector.newBuilder().setEnable(true).build())
.build();
从代码可以清晰看出，想要实现按业务线、文档类型双条件过滤的向量检索，仅需要简单配置Filter参数即可，代码逻辑清晰、调试简单，几乎不会出现隐性bug。对比Milvus繁琐的分离式配置，开发效率提升不止一倍。
除此之外，Qdrant提供的REST API调试体验极其友好，研发人员无需编写复杂代码，仅通过curl命令就能快速调试接口、验证检索效果，问题定位效率极高，对于快速迭代、频繁调优的业务场景来说，适配性拉满。
3.2 不可忽视的短板，大数据场景存在天然瓶颈
没有完美的技术框架，Qdrant在轻量化、易用性上做到了极致，但在大数据量、超大规模集群场景下，存在无法规避的天然短板。
首先是索引类型过于单一，Qdrant核心仅支持HNSW一种主流索引，虽然这种索引在百万级、千万级数据量下表现稳定，但面对上亿级超大数据体量时，可调优空间极小。对比Milvus多索引适配、灵活切换的能力，Qdrant在超大数据场景下的性能优化、资源适配能力差距明显，无法应对极致的大数据检索工况。
其次是集群扩展能力不足，Qdrant虽然支持集群部署，但架构设计偏向单机轻量化，集群扩容逻辑不如Milvus的存算分离架构纯粹。当数据量突破亿级、并发量达到超高峰值时，Qdrant会出现明显的性能瓶颈，横向扩容的性价比和稳定性，远不如Milvus稳定可靠。
最后是生态细节的短板，Qdrant的Java SDK文档质量一般，部分API的设计逻辑较为晦涩，日常开发使用基本不受影响，但遇到复杂场景、特殊需求时，查阅文档很难快速找到解决方案，需要大量试错调试，偶尔会影响迭代效率。
四、实打实生产压测数据，破除主观认知偏差
为了让对比结果更加客观，我基于统一的硬件配置、统一的业务数据，对两款数据库做了标准化生产压测，彻底还原真实业务场景的性能表现。本次压测机器配置为8核16G服务器，测试数据为1200万条真实业务向量数据，分别测试纯向量检索、带多条件过滤检索两种核心场景，最终实测数据如下：
纯向量检索场景下，Milvus的P99延迟为8ms，Qdrant的P99延迟为12ms，无过滤条件的基础检索中，Milvus凭借更成熟的索引算法和架构优化，性能优势明显，响应速度更快，高并发稳定性更优。
带多条件过滤检索场景下，局势彻底反转，Milvus的P99延迟达到15ms，而Qdrant的P99延迟仅为9ms，过滤场景下Qdrant实现了反超。
这个数据差异的核心原因，正是两款数据库的架构逻辑不同。Qdrant的过滤逻辑是嵌入向量检索全过程，边过滤、边检索，一步到位完成数据筛选与召回，无冗余步骤。而Milvus是先完成全量范围的向量检索，再对检索结果做二次标量过滤，多了一层数据处理工序，自然产生了性能损耗，数据量越大、过滤条件越复杂，性能差距就越明显。
同时在资源占用方面，同等条件下Milvus整套集群内存占用约4G，而Qdrant仅需2.5G，轻量化优势十分显著。再结合部署架构来看，Milvus需要依赖etcd、MinIO、Pulsar三大组件，部署架构复杂，而Qdrant无任何额外依赖，单容器即可完成部署运维。
这组实测数据也印证了我一直以来的观点，两款数据库不存在绝对的优劣，仅仅是场景适配度不同。脱离业务场景谈性能、比优劣，完全没有实际意义。
五、实战沉淀的选型逻辑，覆盖90%向量数据库落地场景
经过半年多的双库生产落地，我彻底摒弃了网上碎片化的选型经验，总结出一套简单、精准、可直接落地的选型标准，适配绝大多数企业RAG知识库、语义检索项目，大家可以直接对照自身业务场景套用。
首先是中小数据量场景，数据总量在百万级及以内的项目，无脑选择Qdrant即可。这类场景数据体量小、并发压力低，Milvus的高性能、可扩展优势完全无法发挥，反而会因为复杂的架构带来额外的运维成本和资源浪费。而Qdrant部署简单、上手快速、过滤能力强，能够用最低的成本满足全部业务需求，性价比拉满。
其次是超大参数量、高并发纯检索场景，数据量达到千万级以上，且业务以纯向量语义召回为主，几乎不需要复杂元数据过滤，优先选择Milvus。Milvus丰富的索引策略、极致的检索性能、成熟的存算分离扩容架构，能够完美支撑超大数据体量和高峰值并发，保障系统长期稳定运行，这是Qdrant无法企及的优势。
最后是强过滤、精细化检索场景，无论数据量大小，只要业务需要频繁使用多条件组合元数据过滤，优先考虑Qdrant。即便数据量达到千万级，Qdrant的过滤性能优势，也能远超Milvus，开发效率和业务稳定性的提升，足以覆盖它微弱的大数据扩容短板。
除此之外，我想额外补充一个极其重要的选型认知，也是很多新手容易踩的坑，不要为了跟风技术选型盲目上向量数据库。如果你的业务数据仅有几万条，完全不需要部署专用向量数据库，直接使用MySQL、PostgreSQL等普通数据库，新增Embedding向量列，通过暴力扫描的方式就能满足检索需求。向量数据库的部署、运维、迭代都有成本，盲目选型只会增加系统复杂度，属于典型的过度设计。
六、最终落地方案与深度复盘，双库共存才是最优解
基于两款数据库的特性差异，我们公司最终放弃了单库适配全场景的方案，采用Milvus加Qdrant双库并存的落地架构，两款数据库各司其职，分别适配不同业务场景，整体系统的稳定性和迭代效率实现了质的提升。
我们将内部核心大数据量、高并发、少过滤的知识库检索业务，交由Milvus承载，依靠它强大的性能和扩容能力，保障核心业务的稳定输出。而客户侧轻量化、需要频繁多条件过滤、迭代更新快的文档问答业务，则全部使用Qdrant承载，依靠它低运维、高灵活、强过滤的优势，降低项目落地成本。
这种双库架构虽然会增加少量的运维工作量，需要同时维护两套向量数据库环境，但相比硬套单一数据库适配所有场景带来的性能短板、开发低效、运维隐患，性价比极高，能够完美适配所有业务工况。
复盘这大半年的落地经历，我最大的感悟就是，技术测评永远要以生产环境为核心，Demo环境的流畅运行不代表生产环境的稳定可用。本地测试只能验证基础功能是否可用，而真实的运维复杂度、高并发稳定性、复杂场景适配能力、长期迭代成本，只有上线落地、经过真实流量打磨后才能真正感知。
很多研发人员选型时，一味追求技术新潮、参数极致，盲目选择功能最全、性能参数最高的框架，却忽略了自身团队的运维能力、业务的真实场景需求。技术选型的核心从来不是选最强的技术，而是选最适配自身业务、最贴合团队能力的技术。
七、后续技术迭代规划
向量检索仅仅是RAG智能问答系统的核心环节之一，一套完整的高性能RAG链路，还包含文档切块、向量化处理、召回策略优化、重排筛选、答案生成校验等多个核心步骤，每个环节都存在大量容易踩坑的细节。
