[AI/RAG/Memory/VectorDB] 技术调研：AI 应用的向量存储

0 序

  • 向量存储作为 AI 应用中记忆模块、上下文管理模块、RAG模块中不可或缺的数据存储组件，成为近2-3年来数据库领域最火热的新兴方向。

1 技术调研：AI 应用的向量存储

  • 如果把下述结论放到前面研究的“企业级 AI Agent 平台”整体架构里，则会进一步把它抽象成一个更完整的「Enterprise Retrieval Architecture」：Knowledge Platform → Indexing Platform → Vector/Search Layer → Retrieval Service → Reranker → Context Engine → AI Agent Runtime，再详细划分 Qdrant/Milvus/pgvector/ES 分别应该落在哪一层，以及 Knowledge、Memory、Context、Skill 与 Vector Store 的边界。

[AI/Agent/架构] 企业级AI应用的架构设计（参考蓝图） - 博客园/千千寰宇

核心结论

  • 结论先行：

对绝大多数企业级 AI/RAG/Agent 项目，不要先问“哪个向量数据库性能最高”，而应该先问：

  1. 向量数据规模是多少？
  2. 是否已经有 PostgreSQL / Elasticsearch？
  3. 是准备“数据库里顺便加向量能力”，还是“以向量检索为核心的基础设施”？
  4. 是否需要复杂 Metadata Filter？
  5. 是否需要 Dense + Sparse + BM25 Hybrid Search？
  6. 是否需要多租户？
  7. 是否需要 Multivector / ColBERT / 多模态？
  8. 是否允许云托管？
  9. 运维团队有没有能力维护一个独立分布式数据库？
  • ChatGPT 的默认推荐顺序：
  • 已有 PostgreSQL、数据规模中小、业务数据与向量强关联 → pgvector
  • 纯 AI/RAG、复杂过滤、多向量、希望专门做【向量检索】 → Qdrant
  • 超大规模、100M～10B+ 向量、需要【独立向量基础设施】 → Milvus（数量级≥千万级）
  • 已有 Elasticsearch、强关键词/BM25/全文检索需求 → 【Elasticsearch】
  • 希望“AI 原生数据库 + Hybrid Search + 多租户” → Weaviate
  • 不想运维、希望直接托管 → Pinecone
  • 【开发体验优先】、【原型/中小规模】 AI 应用 → Chroma
  • 特别重要：不要把 Milvus、Qdrant、pgvector、Elasticsearch、Pinecone 简单理解成“7 个同质化产品”。

它们实际上分属不同的架构路线。

研究范围与核心判断框架

本文比较：

组件 核心定位
Milvus 云原生、分布式、专用向量数据库
pgvector PostgreSQL 向量扩展
Qdrant AI-native / Vector-first 向量数据库
Chroma 开发者友好的 AI 数据基础设施 / 向量数据库
Weaviate AI-native、Vector-first、Hybrid Search 数据库
Elasticsearch 搜索/分析引擎，同时提供成熟 Vector Search
Pinecone 全托管 Serverless Vector Database
  • Milvus 官方将自身定位为面向大规模、高维向量相似性搜索的云原生向量数据库，并采用存储计算分离架构；
  • pgvector 则直接把向量能力嵌入 PostgreSQL；
  • Qdrant、Weaviate 更强调 Vector-first / AI-native；
  • Elasticsearch 则是在成熟搜索引擎基础上增加 Dense/Sparse Vector；
  • Pinecone 则走完全托管的云服务路线。

先理解：AI 应用为什么需要“向量存储”

  • 典型 RAG / Agent 数据流：
flowchart LR A[原始数据<br/>PDF/Word/网页/数据库] --> B[解析] B --> C[Chunking] C --> D[Embedding Model] D --> E[Vector] C --> F[Metadata] E --> G[(Vector Store)] F --> G Q[用户 Query] --> H[Query Embedding] H --> G G --> I[Top-K Retrieval] I --> J[Reranker] J --> K[Context] K --> L[LLM] L --> M[Answer]

向量数据库实际上解决的是：

“如何从大量数据中，快速找到与当前 Query 在语义空间中最相似的对象。”

但现代 AI 应用已经不只是：

Vector → TopK

而往往变成：

Dense Vector
      +
Sparse Vector / BM25
      +
Metadata Filter
      +
Tenant Filter
      +
Permission Filter
      +
Time Filter
      +
Reranking
      +
Multi-vector

所以今天选择 Vector Store，实际上是在选择一个：

Retrieval Infrastructure（检索基础设施）

而不仅仅是一个“存向量的数据库”。

七个产品首先应该分成 4 条技术路线

这是理解整个选型问题最重要的一张表。

技术路线 产品 核心思想 最适合
PostgreSQL 扩展路线 pgvector 让 PostgreSQL 获得 Vector Search 业务系统 + RAG
专用 Vector DB 路线 Milvus 从底层为海量向量检索设计 超大规模
AI-native Vector DB Qdrant / Weaviate Vector-first + Filter + Hybrid + AI 企业 RAG / Agent
Search Engine 路线 Elasticsearch 全文搜索 + Vector Search Search + RAG
Managed SaaS 路线 Pinecone 不运维数据库，直接调用服务 云端 AI
Developer-first 路线 Chroma 极低门槛 + AI 应用开发体验 原型 / 中小应用

可以抽象成：

quadrantChart title Vector Store 技术路线 x-axis "业务数据库融合" --> "专用向量基础设施" y-axis "自运维" --> "完全托管" "pgvector": [0.15, 0.25] "Milvus": [0.90, 0.30] "Qdrant": [0.72, 0.35] "Weaviate": [0.70, 0.45] "Elasticsearch": [0.45, 0.30] "Chroma": [0.35, 0.50] "Pinecone": [0.80, 0.95]

上图是架构定位示意，不是性能 Benchmark。

核心能力总览-综合能力矩阵

评分采用：

  • ★★★★★：非常强
  • ★★★★☆：强
  • ★★★☆☆：中等
  • ★★☆☆☆：偏弱
  • ★☆☆☆☆：不适合作为主要能力
维度 Milvus pgvector Qdrant Chroma Weaviate Elasticsearch Pinecone
向量检索 ★★★★★ ★★★★☆ ★★★★★ ★★★★☆ ★★★★★ ★★★★☆ ★★★★★
超大规模 ★★★★★ ★★★☆☆ ★★★★☆ ★★★☆☆ ★★★★☆ ★★★★★ ★★★★★
CRUD 易用性 ★★★★☆ ★★★★★ ★★★★★ ★★★★★ ★★★★☆ ★★★★☆ ★★★★★
Metadata Filter ★★★★☆ ★★★★★ ★★★★★ ★★★★☆ ★★★★★ ★★★★★ ★★★★☆
Hybrid Search ★★★★★ ★★★★☆ ★★★★★ ★★★★★ ★★★★★ ★★★★★ ★★★★★
BM25/全文搜索 ★★★☆☆ ★★★★☆ ★★★☆☆ ★★★★☆ ★★★★☆ ★★★★★ ★★★★☆
Sparse Vector ★★★★★ ★★★★★ ★★★★★ ★★★★☆ ★★★★☆ ★★★★★ ★★★★★
Multivector ★★★★★ ★★★☆☆ ★★★★★ ★★★☆☆ ★★★★☆ ★★★☆☆ ★★★☆☆
多模态 ★★★★★ ★★★☆☆ ★★★★★ ★★★★☆ ★★★★★ ★★★★☆ ★★★★☆
多租户 ★★★★☆ ★★★★★ ★★★★★ ★★★★★ ★★★★★ ★★★★★ ★★★★★
分布式扩展 ★★★★★ ★★★☆☆ ★★★★☆ ★★★★☆ ★★★★★ ★★★★★ ★★★★★
数据库事务 ★★★★★ ★★★★★ ★★★☆☆ ★★★☆☆ ★★★☆☆ ★★★☆☆ ★★★☆☆
SQL ★☆☆☆☆ ★★★★★ ★☆☆☆☆ ★☆☆☆☆ ★☆☆☆☆ ★★☆☆☆ ★☆☆☆☆
运维复杂度 ★★☆☆☆ ★★★★★ ★★★★☆ ★★★★★ ★★★☆☆ ★★☆☆☆ ★★★★★
K8s 适配 ★★★★★ ★★★★☆ ★★★★★ ★★★★☆ ★★★★★ ★★★★★ N/A
云托管 ★★★★★ ★★★★★ ★★★★★ ★★★★★ ★★★★★ ★★★★★ ★★★★★
开源自部署 ★★★★★ ★★★★★ ★★★★★ ★★★★★ ★★★★★ ★★★★★ ☆
Vendor Lock-in 低 很低 低 低 中 中 高
开发门槛 中 低 低 很低 中 中高 很低

七个产品的本质区别

pgvector：不是“向量数据库”，而是“PostgreSQL + Vector”

这是非常重要的认知。

pgvector 本质：

PostgreSQL
   │
   ├── Relational Data
   ├── Transaction
   ├── SQL
   ├── JSONB
   ├── Full Text Search
   ├── B-Tree / GIN / GiST
   │
   └── pgvector
          ├── vector
          ├── HNSW
          ├── IVFFlat
          ├── halfvec
          ├── sparsevec
          └── binary quantization

当前 pgvector 支持 HNSW、IVFFlat，并支持 vector、halfvec、bit、sparsevec 等类型；还可以与 PostgreSQL 的全文检索结合实现 Hybrid Search。(GitHub)

最大优势

假设你的业务：

users
orders
products
documents
document_chunks
permissions
embeddings

全部都已经在 PostgreSQL。

那么：

SELECT ...
FROM document_chunks
WHERE tenant_id = ?
  AND permission = ?
ORDER BY embedding <=> ?
LIMIT 10;

这实际上非常漂亮。

你不需要：

PostgreSQL
        ↓
同步数据
        ↓
Milvus/Qdrant
        ↓
维护双写
        ↓
处理一致性

而是：

             PostgreSQL
                  │
       ┌──────────┴──────────┐
       │                     │
 Relational Data       Vector Search
       │                     │
       └──────────┬──────────┘
                  ↓
               RAG

pgvector 最大短板

当你开始要求：

10亿+
高 QPS
大量 ANN
复杂多租户
多向量
大规模分片
独立 Vector Cluster

PostgreSQL 就逐渐不是最自然的架构。

pgvector 官方目前仍然把横向扩展更多建立在 PostgreSQL Replication、Citus、PgDog 等外围方案之上，而不是像 Milvus 那样原生设计成 Vector Cluster。(GitHub)

Milvus：真正意义上的“Vector Infrastructure”

Milvus 的核心思想是：

Vector Search 本身就是一个独立的大规模基础设施。

架构非常典型：

flowchart TB Client[AI Application] Client --> Proxy[Proxy / Access Layer] Proxy --> Coord[Coordinator] Coord --> Query[Query Nodes] Coord --> Data[Data Nodes] Coord --> Stream[Streaming Nodes] Query --> Cache[Memory / SSD] Query --> Object[(Object Storage)] Data --> Object Data --> WAL[(WAL)] Coord --> Meta[(Metadata Store)] Object --> S3[S3 / MinIO]

Milvus 2.6 架构强调控制面与数据面解耦，以及计算与存储分离；Query Node、Data Node、Streaming Node 等角色分别负责查询、数据处理和流式数据处理。(Milvus)

Milvus 最强的地方

规模。

官方部署建议中：

模式 官方定位
Milvus Lite 小规模，几百万 vectors
Standalone 中等规模，约 100M vectors
Distributed 100M ～ 数十亿 vectors

(Milvus)

所以如果你的架构目标是：

10M
100M
1B
10B+

那么 Milvus 的架构合理性会越来越明显。

Milvus 另一个强项：多向量

它支持：

Dense Vector
Sparse Vector
Text
Image
Audio
Multiple Vector Fields
Hybrid Search

例如一个对象：

Document
├── title_embedding
├── body_embedding
├── image_embedding
└── sparse_embedding

可以进行 Multi-Vector Hybrid Search。(Milvus)

Qdrant：ChatGPT 认为目前企业 AI/RAG 非常值得优先考虑的 Vector DB

Qdrant 的设计哲学非常明确：

把 Vector Search 做成一个现代化、高性能、开发友好的数据库。

Qdrant 使用 Rust 实现，并以 Point + Vector + Payload 为核心数据模型。(GitHub)

flowchart LR P[Point] P --> ID[ID] P --> V1[Dense Vector] P --> V2[Sparse Vector] P --> V3[Multi Vector] P --> Payload[Payload] Payload --> F1[Tenant] Payload --> F2[Document] Payload --> F3[Permission] Payload --> F4[Timestamp] Payload --> F5[Business Metadata]

这是 Qdrant 特别适合 RAG 的原因。

例如：

{
  "id": "chunk_123",
  "vector": [...],
  "payload": {
    "tenant_id": "company_A",
    "department": "finance",
    "document_type": "contract",
    "year": 2026,
    "permission": "internal"
  }
}

然后：

Semantic Search
       +
tenant_id = A
       +
department = finance
       +
year >= 2025
       +
permission = internal

Qdrant 官方对 Payload Filtering 有比较完整的设计，并支持 Payload Index。(Qdrant)

Qdrant 的一个杀手级能力：Multivector

Qdrant 支持：

Dense
Sparse
Multivector
Named Vector

尤其是：

ColBERT
Late Interaction
Multi-modal

这种场景。

一个 Point 可以保存多个不同类型/用途的 Vector；Multivector 可以保存一个对象对应的一组 Dense Vectors。(Qdrant)

这意味着：

flowchart LR D[Document] D --> E1[Dense Embedding] D --> E2[Sparse Embedding] D --> E3[ColBERT Token Vectors] D --> E4[Image Embedding] E1 --> Q[Retrieval] E2 --> Q E3 --> Q E4 --> Q Q --> R[Rerank]

对于下一代 Agent/RAG 系统，这种能力很有价值。

Weaviate：Vector Database + AI Search Platform

Weaviate 与 Qdrant 很接近，但更强调：

Vector
+
Keyword
+
Hybrid
+
RAG
+
AI Integration
+
Multi-tenancy

Weaviate 原生支持：

  • HNSW
  • Flat
  • Dynamic
  • HFresh
  • BM25
  • Hybrid Search
  • Metadata Filtering
  • Multi-tenancy
  • Replication
  • Sharding

其 Hybrid Search 会同时执行：

Vector Search
+
BM25 Search

再合并结果。(Weaviate 文档)

Weaviate 的一个有意思的设计

Dynamic Index：

< 10K objects
      ↓
Flat

> 10K objects
      ↓
HNSW

即：

flowchart LR A[Small Dataset] --> B[Flat Index] B -->|Dataset grows| C[HNSW]

官方文档说明 Dynamic Index 可以从 Flat 动态切换到 HNSW，并且默认阈值为 10,000 objects。(Weaviate 文档)

这对：

大量小租户，每个租户只有几千/几万文档

这种 SaaS AI 应用很有价值。

Elasticsearch：如果你的问题本质是“搜索”，不要为了 RAG 抛弃 ES

Elasticsearch 是这 7 个里面最容易被误判的。

它不是传统意义上的 Vector DB。

它首先是：

Search Engine

然后 Vector Search 成为了它越来越重要的能力。

目前 Elasticsearch 支持：

BM25
Dense Vector
Sparse Vector
kNN
Hybrid Search
RRF
Filtering
Aggregations
Full Text Search
Geo Search
Analytics

官方 Hybrid Search 推荐通过 RRF 将全文检索和 Vector Search 结果进行融合。(Elastic)

架构上：

flowchart TB Q[Query] Q --> BM25[BM25] Q --> Dense[Dense Vector] Q --> Sparse[Sparse / ELSER] BM25 --> RRF[RRF] Dense --> RRF Sparse --> RRF RRF --> Result[Unified Ranking]

所以：

如果你的项目是： 企业搜索+知识库+日志+全文检索+RAG+Filter+聚合分析 => 选 ES

企业搜索
+
知识库
+
日志
+
全文检索
+
RAG
+
Filter
+
聚合分析

那么 Elasticsearch 可能比专用 Vector DB 更合理。

这是它相对于纯 Vector DB 的一个巨大优势。

比如用户搜索：

“宝马 X5 2025款 变速箱故障代码 P0730”

纯向量搜索可能理解：

变速箱故障
Transmission
Gearbox

但用户真正需要的是：

P0730
X5
2025

这些是精确 Token。

所以最合理的是：

Dense Search
     +
BM25
     +
Metadata Filter
     ↓
RRF
     ↓
Reranker

Elasticsearch 在这个方向非常强。(Elastic)

Chroma：开发者体验非常优秀，但要正确认识它

Chroma 早期非常典型：

client = chromadb.Client()
collection = client.create_collection(...)

几分钟就能完成：

Embedding
+
Metadata
+
Vector Search

现在的 Chroma 已经不仅是“玩具”。

官方架构已经包括：

Local
Single Node
Distributed
Chroma Cloud

Distributed Chroma 采用：

Gateway
Log
Query Executor
Compactor
System Database
Object Storage
SSD Cache

的架构。(Chroma Docs)

并且已经支持：

Dense
Sparse
Hybrid
Metadata Filter
Full Text
Regex
Multi-modal

(Chroma Docs)

所以现在不能再简单说：Chroma = 只能做 Demo

Chroma = 只能做 Demo

这是过时判断。

但从企业长期基础设施的角度，我仍然会把：

Milvus
Qdrant
Weaviate
Elasticsearch

放在 Chroma 前面。

原因不是“Chroma 不行”，而是：

企业级 Vector Infrastructure 的生态成熟度、架构经验和长期运维经验仍然是更重要的考虑因素。

Pinecone：核心卖点不是算法，而是“不让你操心的云数据库”

Pinecone 的核心竞争力：

Managed Vector Database

也就是说：

你不想管理：

Kubernetes
+
Shard
+
Replica
+
HNSW
+
Object Storage
+
Failover
+
Scaling
+
Capacity Planning

↓

Pinecone

Pinecone 当前以 Serverless Index 为主要路线；传统 Pod-based Index 已经成为 Legacy，新客户自 2025 年 8 月起不能创建 Pod Index。(Pinecone Docs)

它现在已经不仅支持 Dense Vector：

Dense Vector
Sparse Vector
BM25 / Full Text
Metadata
Namespaces
Hybrid Retrieval

单个 Serverless Index 可以同时包含 dense、sparse、full-text 字段。(Pinecone Docs)

七者的架构对比

这是 ChatGPT 认为最重要的一张表。

维度 Milvus pgvector Qdrant Chroma Weaviate Elasticsearch Pinecone
本质 Vector DB PG Extension Vector DB AI DB Vector DB Search Engine Managed Vector DB
数据模型 Collection Table Collection/Point Collection Collection/Object Index/Document Index/Record
核心索引 HNSW/IVF/DiskANN 等 HNSW/IVF HNSW HNSW 等 HNSW/Flat/HFresh HNSW/BBQ 等 Managed
SQL ❌ ✅ ❌ ❌ ❌ 类 DSL ❌
Transaction 强 强 弱于 PG 弱于 PG 弱于 PG 非关系事务 Managed
Vector-first ★★★★★ ★★☆☆☆ ★★★★★ ★★★★☆ ★★★★★ ★★★☆☆ ★★★★★
Search-first ★★★☆☆ ★★★☆☆ ★★★★☆ ★★★★☆ ★★★★☆ ★★★★★ ★★★★☆
Scale-out ★★★★★ ★★★☆☆ ★★★★☆ ★★★★☆ ★★★★★ ★★★★★ ★★★★★
运维 高 低 中 低～中 中高 高 极低

向量规模应该如何影响选择？

不能简单说：

1000 万 = A
1 亿 = B

因为真正决定架构的不是单纯 Vector Count，而是：

Vector Count
×
Dimension
×
QPS
×
Recall
×
Filter Selectivity
×
Write Rate
×
Update Rate
×
Multi-tenancy

一个更合理的粗粒度模型 => 数据量级:推荐组件 （必读）

规模 推荐重点
< 10 万 pgvector / Chroma
10 万～1000 万 pgvector / Qdrant / Weaviate / ES
1000 万～1 亿 Qdrant / Milvus / Weaviate / ES
1 亿～10 亿 Milvus / Qdrant / Weaviate / ES
10 亿以上 Milvus / Pinecone / 大规模 ES
10B+ Milvus / 专门云 Vector Infrastructure

注意：这不是性能 Benchmark，而是【架构选型经验区间】。

Chroma 官方自己的单节点测试已经覆盖到数百万乃至接近千万级 embeddings，并明确说明更大规模应该考虑 Distributed。(Chroma Docs)

Milvus 官方则明确将 Distributed 模式定位到 100M 至数十亿级数据。(Milvus)

Embedding Dimension 也非常重要

例如：

1,000,000 vectors
×
1536 dimensions
×
4 bytes

仅原始 FP32 Vector 就大约：

6.14 GB

还没算：

HNSW
Metadata
Index
Replica
OS
Cache
Storage

如果：

100M vectors
×
1536

原始向量已经达到：

614 GB

所以：

“向量数量”与“向量维度”必须一起看。

Quantization 会成为企业级 Vector DB 的核心能力

典型：

FP32
 ↓
FP16
 ↓
INT8
 ↓
Binary

可以显著减少：

Memory
Storage
IO

Qdrant 提供 Scalar / Product / Binary Quantization。(Qdrant)

Elasticsearch 当前也提供 BBQ、INT8、INT4 等 Vector Quantization 策略，其中 BBQ 可以大幅降低内存占用。(Elastic)

pgvector 也已经支持 halfvec 和 Binary Quantization。(GitHub)

因此：

flowchart LR A[100M FP32 Vectors] --> B[Quantization] --> C[Smaller Index] --> D[Lower RAM] --> E[Lower Cost] --> F[Higher Throughput]

但要注意：

Quantization 永远不是免费午餐。

通常存在：

Memory ↓
Storage ↓
Latency ↓
Cost ↓
Recall ↓

之间的 Trade-off。

Metadata Filtering 是 RAG 项目中经常被低估的能力

很多人选 Vector DB 只看：

QPS
Recall
Latency

这是错误的。

企业 RAG 更重要的是：

Query
   ↓
Tenant Filter
   ↓
Permission Filter
   ↓
Department Filter
   ↓
Document Type Filter
   ↓
Time Filter
   ↓
Vector Search

例如：

“查一下 2025 年以后，成都研发部门可以访问的新能源汽车电池故障文档。”

实际上可能是：

tenant = xxx
AND
department = R&D
AND
city = Chengdu
AND
year >= 2025
AND
document_type = fault
AND
permission = internal

然后才：

Vector Search

Filter 能力对比

产品 Metadata Filter Filter Index 复杂 Filter Filter + ANN
Milvus ★★★★★ ★★★★★ ★★★★★ ★★★★★
pgvector ★★★★★ ★★★★★ ★★★★★ ★★★★☆
Qdrant ★★★★★ ★★★★★ ★★★★★ ★★★★★
Chroma ★★★★☆ ★★★★☆ ★★★★☆ ★★★★☆
Weaviate ★★★★★ ★★★★★ ★★★★★ ★★★★★
ES ★★★★★ ★★★★★ ★★★★★ ★★★★★
Pinecone ★★★★☆ ★★★★☆ ★★★★☆ ★★★★☆

Qdrant、Milvus、pgvector、Pinecone 都有专门的过滤机制；但底层实现不同。比如 pgvector 在 ANN 下可能先扫描 ANN 索引再应用过滤，因此需要使用 iterative scan、partial index 或 partitioning 等手段处理高选择性过滤。(GitHub)

Hybrid Search：企业 RAG 基本应该成为默认能力

现在推荐的 RAG Retrieval：

flowchart TB Q[User Query] Q --> Dense[Dense Vector Search] Q --> Sparse[Sparse Search] Q --> BM25[BM25] Dense --> Candidates[Candidate Fusion] Sparse --> Candidates BM25 --> Candidates Candidates --> RRF[RRF / Weighted Fusion] RRF --> Filter[Business Filter] Filter --> Rerank[Reranker] Rerank --> Context[Context]

为什么？

因为：

Dense 擅长

语义
同义词
意图
上下文

Sparse/BM25 擅长

SKU
型号
错误码
人名
产品编号
法律条款
数据库字段

所以：

Enterprise RAG 不建议长期停留在“纯 Dense Vector Search”。

Milvus、Qdrant、Chroma、Weaviate、Elasticsearch、Pinecone 都已经提供不同形式的 Hybrid Retrieval。(Milvus)

Multi-Tenancy/多租户 怎么选？企业 AI SaaS 特别重要的问题

这是企业 AI SaaS 特别重要的问题。

例如：

Tenant A
 ├── Knowledge Base
 └── Memory

Tenant B
 ├── Knowledge Base
 └── Memory

Tenant C
 ├── Knowledge Base
 └── Memory

常见方案：

方案 A：
一个 Collection + tenant_id filter

方案 B：
每 Tenant 一个 Collection

方案 C：
Namespace

方案 D：
Partition

各产品思路

产品 多租户策略
pgvector tenant_id + PostgreSQL Partition
Milvus Partition Key / Partition
Qdrant Collection / Payload / shard 等
Chroma Tenant / Database / Collection
Weaviate Multi-tenancy
Elasticsearch Index / Alias / Field / Document
Pinecone Namespace

Milvus 提供 Partition Key，可以根据租户等标量字段缩小搜索范围。(Milvus)

Pinecone 则把 Namespace 作为重要的多租户隔离手段，一个 Namespace 中的数据查询不会扫描其他 Namespace。(Pinecone Docs)

Chroma 的模型则是：

Tenant
  ↓
Database
  ↓
Collection

官方将 Tenant 作为顶层隔离概念。(Chroma Docs)

一致性：不要把 Vector DB 当成订单数据库

Vector DB 的数据通常是：

Document
Chunk
Embedding
Metadata

因此绝大多数场景并不需要：

Serializable Transaction

更重要的是：

Search Freshness
Availability
Latency
Recall

例如：

文档刚上传
     ↓
Embedding
     ↓
写入 Vector DB
     ↓
用户马上搜索

如果此时 Search 看不到新数据：

是否可以接受？

这就是 Vector DB 的 Consistency 问题。

Milvus 的一致性模型

Milvus 当前支持：

Strong
Session
Bounded
Eventually

默认是：

Bounded Staleness

也就是说，它允许一定的数据可见性延迟，以换取性能。(Milvus)

Qdrant 的一致性

Qdrant 支持：

write_consistency_factor
read consistency
write ordering

Write Ordering 可以选择：

weak
medium
strong

Strong Ordering 会通过 leader 串行化操作，从而获得更强的一致性保证，但 Leader 故障可能影响写入可用性。(Qdrant)

Weaviate 的一致性模型

Weaviate 很有意思：

Metadata
   ↓
Raft

Data
   ↓
Leaderless Replication

也就是：

flowchart TB W[Weaviate Cluster] W --> Meta[Metadata] W --> Data[Object Data] Meta --> Raft[Raft] Data --> Leaderless[Leaderless Replication]

官方文档明确区分了 Metadata Replication 和 Data Replication。(Weaviate 文档)

运维复杂度：这是企业项目中非常现实的因素

如果自己部署：

pgvector

PostgreSQL

基本已经有了。

Qdrant

Qdrant
  +
K8s
  +
Storage

相对简单。

Weaviate

Weaviate
+
K8s
+
Storage
+
Cluster
+
Replication

中等。

Milvus

可能涉及：

Milvus
├── Proxy
├── Coordinator
├── Query
├── Data
├── Streaming
├── Metadata
├── WAL
└── Object Storage

所以运维复杂度明显更高。

Milvus 当前的云原生架构确实是高度模块化和分布式的，因此换来的扩展能力非常强，但运维复杂度也相应提高。(Milvus)

一个非常重要的判断：不要为了“性能”过早引入 Milvus

假设你现在有：

用户：1000
Documents：50万
Chunks：500万
QPS：50
PostgreSQL 已存在

如果直接：

PostgreSQL
+
Milvus
+
Redis
+
Kafka
+
Object Storage

很可能是：

过度架构。

更合理：

flowchart LR App[AI Application] PG[(PostgreSQL + pgvector)] App --> PG

等到：

Vector = 100M+
QPS = 高
Filter = 复杂
ANN = 核心业务
PostgreSQL = 已经成为瓶颈

再拆：

flowchart LR App[AI Application] App --> PG[(PostgreSQL)] App --> V[(Milvus / Qdrant)] PG -->|Business Data| App V -->|Retrieval| App

这才是合理的演进路径。

推荐的企业 AI 数据架构

结合企业级 Agent / RAG，我更推荐：

flowchart TB Agent[AI Agent] Agent --> Retrieval[Retrieval Service] Retrieval --> Dense[Dense Retrieval] Retrieval --> Sparse[Sparse Retrieval] Retrieval --> Filter[Metadata / ACL Filter] Retrieval --> Rerank[Reranker] Dense --> VectorDB[(Vector DB)] Sparse --> VectorDB Retrieval --> Redis[(Redis Cache)] VectorDB --> PG[(PostgreSQL)] PG --> Business[Business Data] VectorDB --> Object[(Object Storage)] Object --> Documents[Original Documents]

关键思想：

Vector DB 不应该成为 Enterprise Data Platform 的唯一数据源。

Vector DB 与 PostgreSQL / Data Warehouse / Object Storage 的边界

这是企业架构里非常容易混乱的问题。

建议：

数据 最适合
用户/订单/业务实体 PostgreSQL/MySQL
原始 PDF/Word/图片 Object Storage
数据仓库 Lakehouse / Warehouse
Chunk Vector DB / PostgreSQL
Embedding Vector DB
Metadata Vector DB + Business DB
权限 Business DB / IAM
RAG Index Vector DB
原始知识 Knowledge Platform
Retrieval Cache Redis
Search Index ES / Vector DB

因此：

               Enterprise Data
                     │
       ┌─────────────┼─────────────┐
       ↓             ↓             ↓
   OLTP DB       Data Lake      Object Storage
       │
       ↓
   Business Data
                     │
                     ↓
               Knowledge Pipeline
                     │
          ┌──────────┴──────────┐
          ↓                     ↓
     Vector Index          Search Index
          │                     │
      Qdrant/Milvus/       Elasticsearch
      pgvector/etc.

如果你正在做企业级 AI Agent，建议这样选

场景 A：企业内部知识库

100万～1000万 chunks
+
Metadata Filter
+
ACL
+
RAG

推荐

Qdrant / pgvector

优先：

已有 PostgreSQL → pgvector
独立 AI 平台 → Qdrant

场景 B：企业级知识库平台

1000万～1亿 chunks
+
大量 Tenant
+
Hybrid Search
+
Rerank
+
多业务线

推荐

Qdrant
Milvus
Weaviate
Elasticsearch

其中：

重点 推荐
Vector-first Qdrant
Scale Milvus
AI-native Weaviate
Search-first Elasticsearch

场景 C：超大规模向量检索

100M
1B
10B+

第一选择: Milvus

Milvus

原因不是“Milvus 一定比所有产品快”，而是：

它的系统架构从一开始就是围绕这种规模设计的。

Milvus 官方 Distributed 模式明确覆盖 100M 到数十亿级规模，并采用存储计算分离。(Milvus)

场景 D：已经有 Elasticsearch

如果公司已经有：

Elasticsearch
Kibana
Logstash
Search Infrastructure

而 AI 项目需要：

RAG
Semantic Search
BM25
Vector
Hybrid
Filter
Aggregation

我的建议通常是：

优先评估 Elasticsearch，而不是额外引入 Qdrant/Milvus。

因为：

ES
├── BM25
├── Dense
├── Sparse
├── Hybrid
├── RRF
├── Filter
├── Aggregation
└── Analytics

Elasticsearch 当前已经把 Dense Vector、Hybrid Search、RRF 等能力整合进搜索体系。(Elastic)

场景 E：创业公司/快速上线

如果目标：

2周上线
不想维护 DB
团队很小

优先：Pinecone

其次：Qdrant Cloud / Weaviate Cloud / Chroma Cloud

场景 F：本地开发 / Demo / PoC

推荐：

Chroma
pgvector
Qdrant

其中：

目标 推荐
最简单 Chroma
已经使用 PG pgvector
想从 PoC 直接走生产 Qdrant

真正的决策树

这是最推荐实际项目采用的决策方式：

flowchart TD Start[开始选型] Start --> Q1{已有 PostgreSQL?} Q1 -->|是| Q2{向量规模 < 100M 且 QPS 中等?} Q1 -->|否| Q3{已有 Elasticsearch?} Q2 -->|是| PG[优先 pgvector] Q2 -->|否| Q4{Vector 是否成为核心基础设施?} Q3 -->|是| ES[优先 Elasticsearch] Q3 -->|否| Q4 Q4 -->|否| Q5{希望极低运维?} Q4 -->|是| Q6{规模是否 > 100M?} Q5 -->|是| Pine[Pinecone] Q5 -->|否| Q7[Qdrant / Chroma] Q6 -->|是| Milvus[Milvus] Q6 -->|否| Q8{复杂 Filter / Multivector?} Q8 -->|是| Qdrant[Qdrant] Q8 -->|否| Weaviate[Weaviate / Qdrant]

如果只能选一个，我会怎么选？

这其实要分情况。

企业 AI 项目的“默认答案”: Qdrant

我会给：

Qdrant

原因：

Vector-first
+
Filter 强
+
Dense/Sparse
+
Multivector
+
Payload
+
部署相对简单
+
Rust
+
开源
+
Cloud

Qdrant 官方当前的数据模型已经同时覆盖 Dense、Sparse、Multivector、Payload、Filtering、Quantization、Multi-tenancy 等核心 AI Retrieval 能力。(Qdrant)

但是如果企业已经有 PostgreSQL，会改选 pgvector

这是非常重要的例外。

如果：

PostgreSQL 已经是核心 DB
+
Vector < 50M/100M
+
RAG
+
业务过滤
+
权限
+
事务

那么：

pgvector 往往是整个系统复杂度最低、长期成本最低的方案。

因为你少了：

数据同步
+
双写
+
一致性
+
运维
+
监控
+
备份

如果规模非常大，我会选 Milvus

如果目标已经变成：

100M+
1B+
10B+

并且：

Vector Search 本身就是核心基础设施

那么：

Milvus 的架构优势开始真正体现。

如果公司已经大量使用 ES，我会优先 ES

这是很多企业实际项目最容易忽略的。

如果企业已经投入多年：

Elasticsearch Cluster
+
运维体系
+
监控
+
备份
+
Search DSL
+
数据同步体系

那么为了 RAG 再引入：

Qdrant

意味着：

ES
+
Qdrant
+
Data Sync
+
Two Indexes
+
Two Monitoring Systems

不一定划算。

最终推荐矩阵

项目类型 第一选择 第二选择 不优先
PostgreSQL + RAG pgvector Qdrant Milvus
企业知识库 Qdrant Weaviate Chroma
超大规模 Vector Milvus Pinecone pgvector
Search + RAG Elasticsearch Weaviate Chroma
多租户 SaaS RAG Qdrant / Weaviate Pinecone 单纯 pgvector
多模态检索 Qdrant / Milvus Weaviate pgvector
ColBERT / Late Interaction Qdrant Milvus pgvector
极简 PoC Chroma pgvector Milvus
Serverless 云 Pinecone Qdrant Cloud 自建 Milvus
中国企业私有化部署 Qdrant / Milvus / pgvector ES Pinecone
已有 ES 基础设施 Elasticsearch Qdrant Milvus
已有 PG 基础设施 pgvector Qdrant Milvus

对七个组件的最终定位

产品 我的定位 推荐指数 一句话评价
Qdrant ⭐⭐⭐⭐⭐ 9.5/10 当前企业 AI/RAG 非常均衡的 Vector DB
pgvector ⭐⭐⭐⭐⭐ 9.5/10 如果已有 PostgreSQL，往往是第一选择
Milvus ⭐⭐⭐⭐⭐ 9/10 大规模 Vector Infrastructure 首选之一
Elasticsearch ⭐⭐⭐⭐⭐ 9/10 Search + RAG 场景极强
Weaviate ⭐⭐⭐⭐☆ 8.8/10 AI-native + Hybrid + Multi-tenancy 很完整
Pinecone ⭐⭐⭐⭐☆ 8.8/10 不想运维时非常有吸引力
Chroma ⭐⭐⭐⭐☆ 8/10 开发体验优秀，且已经具备真正生产化路线

最重要的架构结论

如果从你前面一直在研究的企业级 AI Agent Platform / Data Platform / Knowledge Platform / MCP / AI Governance架构来看，我建议不要把 Vector DB 当成独立的“知识库”。

更合理的定位是：

flowchart TB Agent[Agent Application] Agent --> Runtime[Agent Runtime] Runtime --> Retrieval[Retrieval Service] Retrieval --> KB[Knowledge Platform] KB --> Parse[Document Processing] KB --> Chunk[Chunking] KB --> Embed[Embedding] KB --> Index[Indexing] Index --> Vector[(Vector Store)] Index --> Search[(Search Engine)] Vector --> Q[Qdrant / Milvus / pgvector] Search --> ES[Elasticsearch] KB --> Object[(Object Storage)] KB --> Meta[(Metadata / ACL)] Meta --> PG[(PostgreSQL)] Runtime --> Memory[Agent Memory] Memory --> Redis[(Redis)]

也就是说：

Knowledge Platform ≠ Vector DB

而是：

Knowledge Platform
│
├── Document Management
├── Parsing
├── Chunking
├── Metadata
├── ACL
├── Embedding
├── Indexing
├── Versioning
├── Retrieval
│
├── Vector Store
│     ├── pgvector
│     ├── Qdrant
│     └── Milvus
│
└── Search Engine
      └── Elasticsearch

这是企业级 AI 架构里非常关键的一层抽象。

最终建议：不要“选 Vector DB”，而应该设计 Retrieval Abstraction

如果是在做真正的企业级 Agent Platform，我甚至不建议业务代码直接写：

qdrant.search(...)

或者：

milvus.search(...)

而应该抽象成：

Retrieval API
     │
     ├── Semantic Search
     ├── Keyword Search
     ├── Hybrid Search
     ├── Metadata Filter
     ├── Multi-vector Search
     ├── Rerank
     └── ACL Filter
             │
             ↓
      Retrieval Adapter
             │
      ┌──────┼────────┐
      ↓      ↓        ↓
   Qdrant  Milvus   pgvector
                     ↓
              Elasticsearch

这样未来：

PoC
 ↓
pgvector
 ↓
Qdrant
 ↓
Milvus

甚至：

Qdrant + Elasticsearch

都可以平滑演进。

最终决策

如果让我给企业 AI 项目制定一条非常简单的选型规则：

业务数据库优先 pgvector；Vector-first 优先 Qdrant；超大规模优先 Milvus；Search-first 优先 Elasticsearch；AI-native + Hybrid 优先 Weaviate；完全托管优先 Pinecone；快速开发优先 Chroma。

而且真正进入生产前，不要相信任何厂商 Benchmark 直接做最终决策。应该使用自己的：

Embedding Model
+
真实 Chunk
+
真实 Metadata
+
真实 Filter
+
真实 QPS
+
真实 Top-K
+
真实 Recall@K
+
真实 Reranker

做 POC Benchmark。

最终应该测：

指标 建议
Recall@5 必测
Recall@10 必测
Recall@20 必测
NDCG@10 推荐
P50 Latency 必测
P95 Latency 核心
P99 Latency 核心
QPS 必测
Insert Throughput 必测
Update/Delete 推荐
Filter Recall 非常重要
Hybrid Recall 非常重要
Multitenant Isolation 企业必测
Cold Start 云环境必测
Memory / Vector 必测
Storage / Vector 必测
运维成本 必测
故障恢复时间 企业必测

真正应该优化的是整个 Retrieval Pipeline，而不是单纯 Vector DB 的 ANN 查询速度。

2 向量存储组件在开源项目与企业中的实际使用情况

向量存储 代表开源项目/生态 代表企业/产品
LanceDB Continue、AnythingLLM、Dosu、Cognee、CodeRabbit、LlamaIndex 集成 字节跳动、Netflix（媒体湖）、WeRide（自动驾驶）、Second Dinner、Runway/Midjourney 类训练数据
Milvus Label Studio（HumanSignal）、Deepset Haystack、Zilliz 生态 Salesforce、PayPal、Airbnb、eBay、NVIDIA、Roblox、IKEA、Chegg、AT&T
Chroma DB-GPT、LangChain chroma 集成、Chroma MCP、各类 RAG 教程默认库 Capital One、UnitedHealthcare、Weights & Biases、Mintlify、Propel
PGVector Supabase Vecs、LangChain PGVector、pgai、pgvectorscale、ParadeDB 混合检索 Postgres/RDS/Aurora 场景常用；Supabase 等提供封装（公开大企业案例较少）
Qdrant Qdrant 自身开源、Edge/混合检索生态 Tripadvisor、OpenTable、HubSpot、Bazaarvoice、Bosch
FAISS 作为底层索引被 LangChain/相似库包装；非完整数据库 Meta 自用、AWS OpenSearch k-NN 引擎选项、Grab、Hugging Face、美团 ES+FAISS
Weaviate Verba（开源 RAG）、Moonsift 等 Morningstar（金融研究助手）、Weaviate Cloud 企业客户

X 参考文献

主要官方资料

推荐文献

posted @ 2026-09-09 19:42  千千寰宇  阅读(14)  评论(0)    收藏  举报