向量数据库（02）：选型与落地——Milvus / Qdrant / pgvector / Weaviate 对比与容量规划

更新时间：2026-09-02。本文是 data-ai/vector-db/ 第 02 篇，在向量数据库索引下。上一篇讲了向量索引原理，这篇讲工程落地：什么时候不用专门向量库、四大主流怎么选、容量怎么估、数据怎么增删改、怎么接进 RAG。

本文要回答的问题

数据量小，有必要上专门向量库吗？pgvector 够不够？
Milvus、Qdrant、Weaviate、Chroma、pgvector 各自适合什么场景？
一千万条 1536 维向量要多少内存/磁盘？怎么估？
文档会更新、删除，向量库怎么处理？多租户怎么隔离？

一、先判断：你真的需要专用向量库吗

向量规模 / 需求                推荐方案
------------------------------------------------
< 10~50 万，已有 PostgreSQL     pgvector（一个扩展，零新组件）
原型/ demo / 万级以内           Chroma / FAISS 本地文件 / LanceDB
百万~亿级，要高可用、过滤、扩展   Milvus / Qdrant / Weaviate
要和全文检索强混合、自建 ES 栈    Elasticsearch/OpenSearch kNN

关键判断：如果你已经在用 PostgreSQL，且向量量在几十万到几百万级，pgvector 往往是最优解——不引入新基础设施、事务/备份/权限全套现成、能和业务表 JOIN。等它成为瓶颈（延迟、规模、过滤性能）再迁移专用库也不迟。不要一上来就为一个内部知识库部署一套分布式 Milvus。

二、主流方案对比

方案	类型	规模上限	亮点	短板
pgvector	Postgres 扩展	单表千万级（HNSW 索引后）	零新组件、SQL/JOIN/事务、运维简单	超大规模、高 QPS、分布式弱
Qdrant	专用（Rust）	亿级	性能强、过滤好、API 友好、资源省	生态较新
Milvus	专用（分布式）	十亿级+	规模最大、云原生、索引类型全	组件多、运维重（依赖 etcd/MinIO/Pulsar）
Weaviate	专用（Go）	亿级	内置模块化向量化/混合检索、GraphQL	定制 embedding 略绕
Chroma	轻量嵌入式	万~百万	上手极快、适合原型	不适合生产大规模
FAISS	库（非服务）	亿级（单机内存）	Meta 出品、极快、灵活	无服务化/持久化/过滤，要自己包
LanceDB	嵌入式列存	千万级	基于 Lance 列存、磁盘友好、零运维	较新

选型直觉：

要省心、已有 PG、数据不大 → pgvector。
生产级、单体服务、强过滤、性价比 → Qdrant。
超大规模/云原生/多租户 SaaS → Milvus（或其托管版 Zilliz）。
要开箱即用的混合检索 + 模块化 → Weaviate。
快速验证想法 → Chroma / LanceDB。

三、容量与内存估算

向量内存主要由"向量本身 + 索引开销"决定。

原始向量体积：
  N 条 × dim 维 × 每维字节数
  float32 = 4 字节/维
  例：1000万 × 1536 × 4B ≈ 61.4 GB（仅原始向量）

索引额外开销：
  HNSW：约为原始向量的 1.2~2 倍（存图的边）
  PQ 压缩：可压到 1/8 ~ 1/32，但损失精度
  还要加：元数据、id 映射、工作内存

经验估算（1000 万 × 1536 维 float32）：

配置	大致内存/磁盘
原始向量	~61 GB
HNSW（含图）	~80~120 GB 内存
IVF-PQ 压缩	~10~20 GB（精度换空间）
磁盘型（LanceDB/Milvus disk index）	可落盘，内存只放索引结构

规划建议：

内存装不下就上 PQ 量化或磁盘索引，别硬扛。
维度不是越高越好：降维/选更小 embedding 模型（如 768 维）能直接砍半成本，精度损失常可接受。
预留 30%~50% 余量给建索引峰值、查询缓存、元数据。

四、增删改与多租户

1. 文档会变怎么办

RAG 里文档会更新、删除。向量库的处理：

插入（upsert）：带唯一 id 写入，重复 id 覆盖。文档重新切块、重新 embedding 后用新 id 或 upsert。
删除：按 id 删除。HNSW 的删除多为"软删除（打墓碑标记）"，大量删除后应定期重建索引回收空间、保召回。
更新策略：文档变更 → 删掉该文档旧 chunk 的所有向量 → 重新切块嵌入 → 写入。建议以"文档 id + chunk 序号"为主键，方便整文档失效。

2. 多租户/权限隔离

方案 A：共享集合 + 元数据过滤字段（tenant_id）
        简单、成本低，靠查询时 filter 保证隔离
        -> 大多数 SaaS 用这个，配合库的过滤能力

方案 B：每租户独立 collection/partition
        隔离强、可独立备份删除，但租户多时元数据爆炸
        -> Milvus 的 partition、Qdrant 的 collection 分组

安全要点：用过滤字段做多租户时，务必在服务端强制注入 tenant_id 过滤条件，不能依赖前端传参，否则越权检索他人数据。

五、接进 RAG 的工程要点

文档 -> 切块(chunk) -> embedding -> 写入向量库(带 metadata:
                                  doc_id / source / 租户 / 时间)
查询 -> 问题 embedding -> 向量库 ANN Top-K (+元数据过滤
                                  +可选 BM25 混合) -> rerank 精排
                            -> 拼进 prompt -> LLM 生成(带来源引用)

落地清单：

chunk 带出处：每个向量存 source/页码/标题，生成时才能给引用、可溯源。
embedding 版本要记录：换模型后旧向量空间不兼容，需要全量重嵌入；metadata 里记 embedding_model 版本。
批量写入：用 bulk/batch insert（每批几百~几千条），别逐条插。
建索引时机：大数据量先批量导入、最后建 HNSW 索引，比边插边建快得多。
监控：跟踪召回延迟、recall@K、空结果率；embedding/rerank 服务的可用性与限流。

小结

选型一句话：已有 Postgres 且数据不大就用 pgvector，生产单体强过滤选 Qdrant，超大规模云原生选 Milvus，原型用 Chroma/LanceDB。容量按 N × dim × 4B 估原始向量、HNSW 再加 1.2~2 倍索引开销，装不下就 PQ 压缩或降维或磁盘索引。文档更新靠"按 doc_id 删旧块→重切块重嵌入"，多租户优先用服务端强制的元数据过滤。向量库只是 RAG 的召回环节，切块、混合检索、重排才是效果上限，见 RAG 架构。

向量数据库

向量数据库（02）：选型与落地——Milvus / Qdrant / pgvector / Weaviate 对比与容量规划 ​

本文要回答的问题 ​

一、先判断：你真的需要专用向量库吗 ​

二、主流方案对比 ​

三、容量与内存估算 ​

四、增删改与多租户 ​

1. 文档会变怎么办 ​

2. 多租户/权限隔离 ​

五、接进 RAG 的工程要点 ​

小结 ​