向量数据库选型：Chroma、Milvus、PGVector 怎么选

本文适合谁：RAG 系统准备或已经上线，需要从原型阶段（Chroma）迁移到生产级向量存储的读者，或者想了解不同向量数据库适用场景的开发者。

向量数据库市场选项繁多：Chroma、Milvus、Qdrant、Pinecone、Weaviate、PGVector、Faiss……每个产品都有各自的定位和适用场景。本文从实际使用角度梳理各选项的特点，帮助开发者根据自身场景做出合理选型。

1.1 向量数据库做什么

传统数据库按精确值检索：WHERE order_id = '20240315001'，要么有要么没有。向量数据库做的是另一件事：给定一个查询向量，找出向量空间里最相近的 K 个向量，也就是 ANN（Approximate Nearest Neighbor，近似最近邻搜索——在海量向量中快速找出"最相似"的几条，不要求绝对精确，换取极快的速度）。

为什么是"近似"？因为精确最近邻在高维空间里计算量爆炸，没法实用。所有向量数据库的核心技术竞争，本质上都是在"检索精度"和"检索速度"之间找平衡，用不同的索引算法实现这个权衡。

存向量 + 高效 ANN 检索，这是向量数据库的核心能力。其他功能（元数据过滤、持久化、分布式、混合检索）都是围绕这个核心展开的。

1.2 主要选项横向对比

向量数据库选型雷达图——Chroma/Milvus/Qdrant/PGVector 在易用性、性能、可扩展性、成本及生产就绪度五维对比

1.3 逐个说清楚

Chroma

最适合入门和快速验证想法。pip install chromadb，三行代码就能跑起来：

import chromadb

client = chromadb.Client()  # 内存模式，进程结束数据消失
# 持久化：chromadb.PersistentClient(path="/tmp/chroma")

collection = client.create_collection("my_docs")
collection.add(
    documents=["苹果是一种水果", "Python 是编程语言"],
    ids=["doc1", "doc2"]
)

results = collection.query(query_texts=["什么是水果？"], n_results=1)
print(results["documents"])
# [['苹果是一种水果']]

Chroma 内置了 Embedding（默认用 all-MiniLM-L6-v2），连 Embedding 模型都不用管。做 Demo 和本地开发，体验极好。

但不适合用在生产。没有高可用，没有水平扩展，大数据量下性能会明显下降，官方也不建议在生产环境使用。

Milvus

开源向量数据库里功能最完整、社区最活跃的选择，也是生产环境的首选。支持多种索引类型（IVF、HNSW、DiskANN——一种基于磁盘存储的向量索引算法，可以在内存有限时用磁盘存储大规模向量），支持分布式部署，支持亿级向量，支持元数据过滤。

代价是部署复杂。Milvus 的完整架构依赖 etcd（一种分布式键值存储系统，用于保存集群的元数据和配置）和 MinIO（一个兼容 S3 协议的开源对象存储服务，用于存放向量索引文件），搭起来需要一定时间。

# 用 Docker Compose 启动 Milvus 单机版
wget https://github.com/milvus-io/milvus/releases/download/v2.4.0/milvus-standalone-docker-compose.yml -O docker-compose.yml
docker compose up -d

如果不想自己运维，Zilliz Cloud 是 Milvus 的全托管版本，国内有节点，API 跟 Milvus 完全兼容。

Qdrant

用 Rust（一种以高性能和内存安全著称的系统编程语言）实现，性能非常好，内存使用效率高。部署比 Milvus 简单得多，一个 Docker（一种将应用和其依赖打包在容器中运行的工具，用一条命令就能启动一个独立的服务进程）容器就能跑：

docker run -p 6333:6333 qdrant/qdrant

支持 payload（元数据）过滤，支持混合检索，支持稀疏向量。Qdrant 是"不想搞 Milvus 那么复杂，但又需要生产级可靠性"的最佳折中。

中等规模（千万向量以内），Qdrant 值得认真考虑。

PGVector

这是最"务实"的选择。如果业务已经在用 PostgreSQL，直接装个插件：

-- 安装扩展
CREATE EXTENSION vector;

-- 创建含向量列的表
CREATE TABLE documents (
    id bigserial PRIMARY KEY,
    content text,
    embedding vector(1536)  -- OpenAI text-embedding-3-small 是 1536 维
);

-- 创建 HNSW 索引
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);

-- 插入向量
INSERT INTO documents (content, embedding) VALUES ('测试文档', '[0.1, 0.2, ...]');

-- 相似度检索
SELECT content, embedding <=> '[0.1, 0.2, ...]' AS distance
FROM documents
ORDER BY distance
LIMIT 5;

不用引入新的基础设施，不用学新的 SDK，用熟悉的 SQL 操作，运维成本接近零。

局限是性能。PostgreSQL 毕竟不是为向量检索设计的，数据量超过百万之后检索速度会明显下降，不如专用向量数据库。但对于很多企业内部场景，百万向量已经够用了。

Pinecone

全托管云服务，注册账号，拿到 API Key，调用就行，运维成本为零。适合不想搭基础设施、快速上线的场景。

缺点是贵，而且数据存在境外服务器。对有数据合规要求的企业，这是硬伤。

1.4 索引类型：FLAT、IVF、HNSW 简单说

向量检索的核心是索引，不同索引有不同的精度和速度权衡。

FLAT（暴力检索）：把查询向量和数据库里每个向量都算一遍距离，取最近的。精度 100%，但数据量大了以后慢得无法接受。只适合数据量极小（几万以内）的场景，或者用来验证其他索引的准确率。

IVF（Inverted File Index，倒排文件索引）：把向量空间分成若干个"桶"（聚类中心），查询时先找最近的几个桶，再在桶内精确搜索。速度比 FLAT 快很多，但有一定精度损失。

HNSW（Hierarchical Navigable Small World，分层小世界图）：目前工程实践中最常用的索引算法。把向量组织成一个多层图结构，检索时从高层快速定位，逐层细化。速度快，精度也相对高，内存占用比 IVF 大。生产环境首选 HNSW。

1.5 距离度量：三种方式

余弦相似度（cosine）：测量两个向量的夹角，不受向量长度影响。文本语义相似度场景首选。值越接近 1，越相似。

欧氏距离（L2）：两点之间的直线距离。受向量长度影响，适合向量已经归一化的场景。

内积（IP，Inner Product，即两个向量逐元素相乘后求和）：等于余弦相似度乘以两个向量的模长之积。适合 embedding 模型输出已经归一化的情况。

大多数场景用 cosine 就对了，除非 embedding 模型的文档里特别说明用别的。

1.6 选型决策树

1.7 选型建议

技术选型的关键不是"哪个更好"，而是当前处于哪个阶段。

刚开始验证想法、写 Demo？用 Chroma，别浪费时间在基础设施上。

已有 PG，数据量不大？用 PGVector，比任何方案都省事，能少引入一个系统就少引入一个。

要上生产，团队有运维能力？优先考虑 Qdrant，部署运维门槛比 Milvus 低，性能足够，功能也够用。数据量特别大、需要精细调优的，再考虑 Milvus。

不想运维，有预算，数据合规不是问题？Pinecone 直接用。

技术选型没有银弹，但有一个原则：优先选择跟现有技术栈摩擦最小的方案。摩擦越小，落地越快。