Milvus 和 PGVector，哪个更好？

前言

在构建RAG应用或推荐系统时，一个绕不开的核心决策是：如何选择向量数据库？

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

市面上选项很多，但讨论最激烈、也是让大家最纠结的，往往就是“二选一”——是选择嵌入在PostgreSQL里的pgvector，还是选择专门的向量数据库Milvus？

这两个工具表面上看都在做同一件事——向量相似度搜索，但本质上代表了两种完全不同的系统设计理念。一个选择将向量检索能力无缝融入现有的成熟数据库生态，另一个则选择为向量检索构建一个独立、专业且高度优化的专用系统。

今天，我们就来深入拆解这两者的差异，希望能帮你做出更清晰的技术选型。

一、两者到底有什么不同？

先给一个结论性的对比：

如果用一个比喻来理解：pgvector就像在你的家庭小厨房里加了一台空气炸锅，偶尔炸个薯条完全够用，还不占地方。Milvus则像一个专业的中央厨房，能同时处理几百桌订单，但你需要单独租场地、雇人、维护设备。

二、它们到底是怎么做向量检索的？

在对比之前，我们先搞懂一个核心问题：向量检索的本质是什么？

简单说，向量检索就是在一堆高维空间里的点中，找到离目标点最近的K个点。如果暴力计算（把所有点都算一遍），数据量一大就慢如蜗牛。所以，必须用索引来加速——就像书的目录，让你不用翻完整本书就能找到内容。

pgvector和Milvus都采用了两种主流索引：IVF（倒排文件索引）和HNSW（分层导航小世界）。但它们的实现方式和优化方向完全不同。

2.1 pgvector的索引原理

pgvector直接在PostgreSQL的存储引擎之上增加了一种新的数据类型vector，并利用PostgreSQL的索引接口实现了IVFFlat和HNSW索引。

IVF原理图：

图片

图片

HNSW原理图：

图片

图片

pgvector把这两种索引算法“塞进”了PostgreSQL的B-tree索引框架中。好处是显而易见的：创建索引的语法和普通B-tree几乎一样，PostgreSQL的查询优化器能自动决定是否使用向量索引。但缺点也很明显——pgvector不能利用多核并行扫描，也无法使用GPU加速，因为PostgreSQL本身的设计并不支持这些特性。

2.2 Milvus的索引原理

Milvus是为向量检索从头设计的系统，它的索引层是一个独立的、高度优化的模块。

Milvus整体架构：

Milvus的索引节点可以并行构建索引，查询节点可以并发执行搜索。它支持10+种索引算法，包括：

• HNSW：基于图的索引，查询快，内存占用大
• IVF_FLAT：聚类+全精度，召回率高
• IVF_PQ：乘积量化，内存压缩8-16倍
• GPU索引：利用CUDA加速，延迟可降至亚毫秒级
• DiskANN：磁盘索引，支持百亿级数据

Milvus的HNSW索引查找过程（多线程并行）：

图片

正是这种“存储计算分离”和“并行执行”的架构，让Milvus在处理千万级以上向量时，性能远超pgvector。

三、核心功能深度对比

3.1 向量类型与索引

pgvector支持稠密向量，索引类型主要为IVFFlat和HNSW。Milvus则支持稠密、稀疏、二值等多种向量类型，索引算法库也更为丰富。

3.2 混合检索能力

pgvector的最大优势是混合检索非常自然——用SQL一条语句就能搞定向量相似度和标量过滤：

SELECT * FROM products
WHERE category = 'electronics'
  AND price < 1000
ORDER BY embedding <=> query_vec
LIMIT 10;

Milvus也支持标量过滤，但过滤条件需要写在表达式里，不如SQL直观：

results = collection.search(
    data=[query_vec],
    anns_field="embedding",
    param={"metric_type": "IP"},
    limit=10,
    expr="category == 'electronics' && price < 1000"
)

3.3 事务与一致性

pgvector继承了PostgreSQL的ACID事务，适合需要强一致性的金融、订单等场景。Milvus则提供最终一致性，更注重高吞吐和低延迟，适合对实时性要求高、允许短暂数据不一致的场景。

3.4 硬件加速

Milvus支持GPU索引（如GPU IVF、GPU HNSW），利用CUDA加速，查询延迟可以降低到亚毫秒级。pgvector目前没有GPU支持，计算完全依赖CPU。

四、性能实测

根据多家机构的基准测试，两者在不同规模下的性能表现差异明显：

百万级向量测试（128维）： 在小数据集下，两者性能差距不大，pgvector甚至因其轻量级开销在某些简单查询上略有优势。

千万级向量测试（768维BERT向量，4节点集群）： 数据量上来后，Milvus的分布式和并行化优势开始显现，写入吞吐量和查询延迟（P99）显著优于pgvector。

结论很清晰：在小规模数据（≤500万）下，pgvector的性能完全够用。但数据量达到千万级以上时，Milvus在写入吞吐量和查询延迟上的优势开始变得非常明显。

五、运维复杂度

这是两者差异最大的维度。

pgvector部署简单到只需一行SQL：CREATE EXTENSION vector;。备份用pg_dump，高可用用repmgr或Patroni，全部复用PostgreSQL生态，不需要学习任何新工具。内存占用方面，100万条以下数据，pgvector可控制在2GB以内。

Milvus部署则需要Docker Compose或K8s环境，即便是单机版，也需要同时运行etcd、MinIO和Milvus三个容器。生产环境集群还需要配置Pulsar或Kafka等消息队列。不过，Milvus 2.6版本做了大量简化工作，例如内置Woodpecker消息队列，降低了对Kafka的依赖。

一句话总结：如果你只有一台2核4G的云服务器，pgvector是最务实的方案；如果你有专门的机器或K8s集群，可以考虑Milvus。

六、代码实战

6.1 pgvector完整示例

-- 1. 安装扩展
CREATE EXTENSION vector;

-- 2. 创建带向量列的表
CREATE TABLE documents (
    id SERIAL PRIMARY KEY,
    content TEXT,
    embedding VECTOR(1536),      -- 1536维嵌入
    category TEXT,
    created_at TIMESTAMP DEFAULT NOW()
);

-- 3. 创建HNSW索引（加速检索）
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);

-- 4. 插入向量数据（假设已有embedding数组）
INSERT INTO documents (content, embedding, category) VALUES
    ('PostgreSQL向量扩展介绍', '[0.12, -0.34, ...]', '技术'),
    ('Milvus分布式向量数据库', '[0.45, -0.12, ...]', '技术');

-- 5. 执行向量相似度检索
SELECT content, 1 - (embedding <=> '[0.11, -0.33, ...]') AS similarity
FROM documents
WHERE category = '技术'
ORDER BY embedding <=> '[0.11, -0.33, ...]'
LIMIT 5;

6.2 Milvus完整示例

技术栈使用的Ja va + Spring AI Alibaba。

pom.xml依赖：

    com.alibaba.cloud.ai
    spring-ai-alibaba-starter-milvus-store
    1.0.0

application.yml配置：

spring:
  ai:
    vectorstore:
      milvus:
        host: localhost
        port: 19530
        collection-name: documents
        embedding-dimension: 1536

Ja va代码：

@Configuration
public class MilvusConfig {
    @Bean
    public VectorStore vectorStore(EmbeddingModel embeddingModel) {
        return new MilvusVectorStore(MilvusVectorStoreConfig.builder()
                .withHost("localhost")
                .withPort(19530)
                .withCollectionName("documents")
                .withEmbeddingDimension(1536)
                .build(), embeddingModel);
    }
}

@Service
public class DocumentService {
    @Autowired
    private VectorStore vectorStore;

    public List search(String query, int topK) {
        // 内部自动完成向量化 + 检索
        return vectorStore.similaritySearch(
            SearchRequest.query(query).withTopK(topK)
        );
    }
}

七、优缺点

pgvector：轻量、简单、够用

优点：

• 部署极简，一行SQL即可启用
• 复用PostgreSQL全套运维体系（备份、高可用、监控）
• 内存占用低（<100万条可控制在2GB）
• 支持ACID事务，数据一致性有保障
• 学习成本几乎为零，直接用SQL
• 混合检索最自然（SQL标量+向量）

局限：

• 数据量超过500万后性能明显下降
• 索引类型有限（无PQ等量化压缩）
• 无内置GPU加速
• 分布式扩展困难，依赖PostgreSQL原生分片方案
• 查询节点单线程执行，无法并行

适用场景： 数据量<500万、已有PostgreSQL基础设施的中小项目、对运维简单性要求极高的团队、需要强事务一致性的场景。

Milvus：专业、强大、可扩展

优点：

• 原生分布式架构，可水平扩展至百亿级向量
• 索引类型丰富（10+种），支持GPU加速
• 写入吞吐量高，延迟低（3-5ms）
• 2.6版本大幅优化内存和成本（INT8压缩）
• 支持多种向量类型（稠密/稀疏/二值）
• 支持动态Schema，灵活适应业务变化

局限：

• 运维复杂度高，需要管理多个组件（etcd、MinIO等）
• 资源门槛较高（默认8GB+内存）
• 学习曲线陡峭
• 与关系型数据的混合查询需要应用层实现
• 不提供ACID事务（最终一致性）

适用场景： 数据量>500万、对查询性能和扩展性要求高的AI应用，如RAG、推荐系统、图像检索、多模态搜索等。

八、如何选择？

图片

总结

回到最初的问题：Milvus和pgvector，哪个更好？

答案很简单：看你的数据规模和业务场景。

• 如果你的业务数据量在百万级以下，或者你已经在用PostgreSQL，希望保持架构简洁，那pgvector就是最务实的选择。一个扩展、几行SQL，就能把向量检索能力接入现有系统，无需额外维护。
• 如果你的数据量达到千万甚至亿级以上，对查询延迟和写入吞吐量有极致要求，且团队有能力维护分布式系统，那Milvus才是正确的答案。

一个普遍的建议是：从pgvector起步，用最简单的方案先跑通业务。等数据量真的涨起来、性能瓶颈真正出现时，再考虑迁移到Milvus也不迟。过早引入复杂的分布式系统，只会增加不必要的运维成本。