向量数据库选型指南：Milvus vs. Pinecone vs. PGVector

去年我在做一个AI知识库项目时，被向量数据库的选型折磨了好几个晚上。Milvus、Pinecone、PGVector这三个名字在技术群里反复出现，但每个都说自己”最合适”。经过两个月的实战踩坑，我决定把真实体验写下来——不是参数对比表，而是踩过坑之后的真心话。

先说说我的选型思路

选向量数据库之前，先想清楚三个问题：数据量多大？（百万级还是亿级）、延迟要求多高？（实时搜索还是离线分析）、团队运维能力如何？（有没有专职DBA）。这三个问题直接决定了你该选哪个方案。

我当时的需求是：每天新增50万条128维向量，查询延迟必须低于200ms，团队只有3个后端开发。这个条件基本排除了需要大量运维投入的方案。

Milvus：开源界的性能怪兽

Milvus是我第一个尝试的方案。它的架构设计很清晰——分成了查询节点、数据节点、索引节点，支持GPU加速，这在开源方案里很少见。

安装体验：用Docker Compose部署确实方便，但版本兼容性是个坑。我第一次部署2.3版本时，发现和Python SDK的版本不匹配，折腾了半小时才跑通。

# 官方推荐的部署方式，但要注意版本号
wget https://github.com/milvus-io/milvus/releases/download/v2.3.0/milvus-standalone-docker-compose.yml
docker-compose -f milvus-standalone-docker-compose.yml up -d

# 安装对应版本的Python SDK
pip install pymilvus==2.3.0

性能表现：在100万条数据量下，HNSW索引的查询延迟稳定在50ms以内，确实很猛。但有个坑——索引构建时内存占用极高。我在8GB内存的服务器上构建IVF_FLAT索引，直接OOM了。后来改用16GB服务器才搞定。

运维痛点：Milvus的组件太多了。etcd、minio、pulsar（或者kafka），任何一个挂了都会影响服务。特别是etcd的集群配置，我遇到过好几次节点失联导致整个集群不可用的情况。如果你团队没有专门的运维，建议直接用Milvus Cloud托管版。

Pinecone：云原生，但钱包会哭

Pinecone是真正的”开箱即用”。注册账号、创建索引、开始写入，整个过程不超过10分钟。不需要关心硬件配置、不需要调参，API设计也很优雅。

# Pinecone的API非常直观
import pinecone

pinecone.init(api_key="your-api-key", environment="us-west1-gcp")

# 创建索引时只需要指定维度和度量方式
pinecone.create_index(
    name="my-index",
    dimension=128,
    metric="cosine"
)

# 写入向量
index.upsert([
    ("id1", [0.1, 0.2, ...], {"metadata_key": "value"}),
    ("id2", [0.3, 0.4, ...], {"metadata_key": "value"})
])

优点很明显：自动扩缩容、零运维、99.99%的SLA。我试过在流量高峰时，Pinecone自动扩展了节点，查询延迟几乎没有波动。

但价格真的太贵了。我算过一笔账：100万条128维向量，用Starter Pod（0.5美元/小时）大概够用，但如果是1000万条，就得用Standard Pod（2美元/小时以上）。一个月下来，光向量数据库就要花上千美元。小团队真的扛不住。

还有一个坑：Pinecone的索引删除后不能立即重建，有冷却时间（大概30秒）。这在开发调试时特别烦人，每次改完索引配置都要等半分钟。

PGVector：够用，但别贪心

PGVector是PostgreSQL的扩展，安装简单到令人感动。如果你的项目已经在用PostgreSQL，加上PGVector几乎零成本。

# 安装PGVector扩展
# 需要PostgreSQL 14以上版本
git clone https://github.com/pgvector/pgvector.git
cd pgvector
make
make install

# 在数据库中启用
psql -U postgres -d mydb -c "CREATE EXTENSION vector;"

实战体验：对于百万级的数据量，PGVector的IVFFlat索引查询延迟在100ms左右，完全够用。而且可以直接用SQL操作，对后端开发非常友好——不需要学习新的查询语法。

-- 创建向量表
CREATE TABLE embeddings (
    id SERIAL PRIMARY KEY,
    embedding vector(128),
    metadata JSONB
);

-- 创建索引
CREATE INDEX ON embeddings USING ivfflat (embedding vector_cosine_ops) WITH (lists = 100);

-- 查询最近邻
SELECT id, metadata, 1 - (embedding <=> '[0.1, 0.2, ...]') AS similarity
FROM embeddings
ORDER BY embedding <=> '[0.1, 0.2, ...]'
LIMIT 10;

但别被它的简单迷惑了。当数据量超过500万条时，PGVector的索引构建速度明显变慢，而且不支持GPU加速。我在一次压力测试中，同时写入和查询，导致整个PostgreSQL实例的CPU飙升到100%，其他业务查询也受影响。

还有个致命问题：PGVector不支持混合搜索（向量+标量过滤）的优化。如果你需要根据metadata字段过滤后再进行向量搜索，性能会急剧下降。我试过在100万条数据中过滤出100条再排序，查询时间从50ms变成了500ms。

我的最终选择：混合方案

经过两个月的折腾，我最终选择了PGVector + Elasticsearch的混合方案。为什么？因为我的业务场景需要精确的metadata过滤（比如按时间范围、用户ID过滤），而纯向量数据库在这方面的支持都不够好。

具体做法：用PGVector存储向量和metadata，用Elasticsearch做全文搜索和精确过滤。查询时先通过Elasticsearch获取符合条件的ID列表，再在PGVector中进行向量搜索。

# 混合搜索伪代码
def hybrid_search(query_vector, filters):
    # 1. 先用Elasticsearch过滤metadata
    es_ids = es.search(
        index="embeddings",
        body={"query": {"bool": {"must": filters}}}
    )
    
    # 2. 再在PGVector中搜索
    results = pg.query(
        "SELECT id, metadata FROM embeddings WHERE id = ANY(%s) ORDER BY embedding <=> %s LIMIT 10",
        (es_ids, query_vector)
    )
    
    return results

踩坑提示：混合方案的关键是ID对齐。确保Elasticsearch和PGVector中的文档ID完全一致，否则会出现数据不一致的问题。我建议用UUID作为主键，并在写入时同时写入两个系统。