向量数据库这么多，RAG场景到底该选哪个？求过来人指点

pgvector真够用，你这量级加过滤查询它稳得很，别折腾专门的向量库了。

pgvector其实被低估了，你这并发不高的话完全够用，还能跟业务库一起事务，省掉同步的麻烦。但几百万条数据加过滤条件，记得要建好HNSW索引再加个类别列上的B-tree，否则过滤会退化。真要上专用库的话，Qdrant的payload过滤和增量更新体验比Milvus省心，Docker单机跑也稳，Milvus那个etcd加MinIO的组合光部署就够喝一壶的。

几百万条其实不算特别大，pgvector加个IVFFlat索引完全能扛，而且你并发不高，过滤条件写SQL也顺手，增量更新直接upsert就行。我之前图省事从faiss迁到pgvector，内存问题直接没了，Docker一个镜像搞定，运维成本低到可以忽略。不过如果你后面数据量涨到几千万，或者检索延迟要求很严，那还是得换专门的向量库，Qdrant的过滤和增量做得比较舒服，但资源占用比pgvector高不少。

看到你说内存扛不住，我建议直接排除faiss，这玩意儿在百万级数据上确实不适合做服务。你这场景并发不高，但又要增量更新和过滤，我实际用下来Qdrant最省心，Docker起个容器就能跑，内存占用比Milvus小不少，过滤的话payload索引效率很高。pgvector我也试过，数据量到几百万后查询延迟会明显上去，而且索引构建时间有点难受，除非你愿意接受过滤条件写得很别扭的SQL。另外提醒下，增量更新别用全量重建，Qdrant和Weaviate都支持按ID upsert，体验会好很多。

pgvector真够了，你这并发又不高，别折腾那些重组件，Docker起个Postgres多省心。

其实你这场景我觉得pgvector真不是不能考虑，几百万条数据如果过滤条件不多，性能差距没那么玄乎，主要是省心。但增量更新和按类别过滤这俩需求，pgvector用起来会有点别扭，尤其索引维护那块。我之前在Qdrant上跑过类似量级，Docker部署挺顺手，内存控制比Milvus轻，过滤查询延迟也稳定。不过你要是更看重社区活跃度和功能全，Milvus还是稳，就是资源占用确实高一些。建议先拿一小部分数据做个压测，别光看文档吹。

几百万条还得带过滤，pgvector真够呛，Qdrant增量更新和Docker部署都省心，内存也比Milvus友好。

按你几百万条的量，pgvector其实挺悬的，过滤条件一多性能掉得厉害，别光看部署省事。我试过Qdrant和Milvus，Qdrant的增量更新和Docker部署确实省心，内存控制也比faiss好不少，但过滤条件复杂时得提前建好索引。Milvus功能全但有点重，单机部署也要调一堆参数，小团队容易踩坑。如果不想折腾，建议先上Qdrant，数据再涨再考虑换。

pgvector确实够用，但你几百万数据加过滤条件，性能会有点悬，别省那点事。

Qdrant走Docker最省心，增量更新和过滤都顺手，我项目里就是这么干的。

pgvector真别急着排除，你几百万量级其实不算大，带过滤条件的话pgvector+索引反而省心，毕竟不用多维护一套基础设施。Milvus和Qdrant我都试过，Milvus部署重但性能稳，Qdrant轻量些，但小并发下差距真没宣传那么大。增量更新这俩都支持，不过你得注意faiss换过去要重写代码逻辑，这块成本别忽略。如果只是知识库问答且不过分追求极致延迟，我建议先pgvector跑通业务，等量真上千万再考虑专用向量库。

说实话你这场景我太熟了，之前做知识库也卡在faiss内存上。几百万条向量其实不算夸张，但faiss全量加载确实吃紧，尤其还得做过滤，纯暴力扫描的话延迟很难看。我个人后来换到Qdrant，Docker一键起，增量更新是默认支持的，而且payload过滤走的是独立索引，不像Milvus那样得先搭一堆依赖组件。Milvus功能强但部署太重，单机模式倒是简单，可数据量上去后性能调优要花不少心思，尤其索引参数和分片策略得反复试。Weaviate也不错，但它的模块化设计对纯RAG场景有点杀鸡用牛刀，资源占用比Qdrant高。至于pgvector，如果你的过滤条件很复杂（比如多字段组合），它可能撑不住高并发下的过滤+向量检索混合查询，但你这并发不高，数据量在千万以内其实完全够用，唯一痛点是索引更新时锁表。我建议你先拿pgvector做个压测，毕竟复用现有PostgreSQL，运维成本最低，真到瓶颈再迁Qdrant也不迟，数据迁移也有现成工具。另外提醒一句，不管选哪个，都记得把embedding模型降维到384或者256，能省一半内存，检索质量掉得没那么明显。

pgvector扛到几百万条加过滤条件会有点吃力，Qdrant的增量更新和Docker部署是真的省心。

pgvector如果能接受性能瓶颈，其实最省心，毕竟不用额外维护组件，但你几百万条embedding加上过滤条件，查询延迟可能会比较难看。我目前用的Qdrant，Docker部署确实方便，增量更新是直接streaming写进去的，不用重建索引，资源占用比Milvus轻不少。Milvus功能全但太吃配置，小团队运维起来会有点痛，Weaviate没长期用过就不评价了。建议你先拿真实数据量跑个benchmark，重点看带过滤条件的召回延迟和内存曲线，别光看官网吹的指标。

pgvector真够用，几百万条加过滤条件没问题，别折腾新东西了。

pgvector其实挺适合你的，几百万量级加过滤条件完全能打，Docker起一个postgres镜像就完事了，省心不少。我之前用过Milvus，部署确实重，但增量更新和稳定性没得挑，就是资源占用有点肉疼。你并发不高的话，别被那些性能评测带偏，先看自己要不要复杂查询，不然纯为RAG折腾分布式有点得不偿失。

pgvector真不是不能考虑，你并发不高的话完全够用，而且跟Postgres生态打通后过滤条件写起来太爽了，不用维护两套系统。不过几百万条纯向量检索用pgvector可能延迟会上去，建议先压测下。Milvus部署重但性能确实猛，Qdrant的话单机Docker挺省心，增量更新和过滤都做得很顺，就是内存占用你得算好。我最后选的是Qdrant，主要看中它的稳定性，跑了大半年没出过幺蛾子。

pgvector真别小看，几百万条加个IVFFlat索引，过滤条件走SQL很顺手，Docker起个实例零负担。我团队之前从FAISS迁过来，内存直接降了70%，增量更新就是普通INSERT，不过查询延迟比专用库高个30%左右，并发低完全能忍。Qdrant我也试过，过滤和增量确实强，但资源占用比pgvector多一截，而且小项目没必要为这功能多维护一个服务。如果你预算敢冒险，可以看看Milvus的Milvus Lite，单机版部署比正式版简单，但稳定性和文档还差点火候。

你这场景其实pgvector真不一定够，几百万条加过滤条件之后性能会下滑得挺明显。我建议直接上Qdrant，Docker起一个实例也就几分钟，增量更新和payload过滤都是原生支持，内存占用比Milvus轻不少。Faiss本地跑本来就不适合动态更新，别硬扛了。如果非要选Milvus，记得单机版部署也挺吃配置的，小团队维护成本略高。

几百万条用pgvector确实省心，但过滤加增量更新多了会有点吃力，Qdrant docker跑起来挺轻的可以试试。

几百万条embedding如果不想折腾，pgvector确实够用，过滤和增量更新都天然支持，Docker起个Postgres就完事。但你要是对检索延迟敏感，Qdrant在中等规模下资源占用和过滤性能会明显舒服一些，单机Docker跑也没啥负担。Milvus功能全但组件多，几百万这个量级有点杀鸡用牛刀了。faiss换掉主要是为了增量，这点上pgvector和Qdrant都能省不少心。