做向量检索选型时，被问得最多的问题就是：用PostgreSQL加pgvector扩展够不够，还是直接上Milvus？这两个方案代表了两条完全不同的技术路线，前者是在成熟的关系型数据库上叠加向量能力，后者是从零开始为向量检索设计的专用系统。选错了轻则性能不达标，重则后期迁移成本巨大。本文从架构、索引、性能、功能等多个角度做一次系统对比，帮你理清决策思路。
一、架构设计思路的根本差异
PostgreSQL是一款有着几十年历史的关系型数据库，它的向量能力来自pgvector这个扩展。pgvector的核心思路是：在PostgreSQL的存储引擎和类型系统里新增一个vector类型，再利用PostgreSQL已有的索引框架实现近似最近邻搜索。这意味着向量数据和普通的结构化数据共存于同一套存储、同一套事务系统里，你可以在一条SQL语句里完成向量检索加条件过滤的混合查询。
Milvus则是云原生架构的专用向量数据库，底层依赖对象存储（如MinIO、S3）存放数据，计算节点与存储节点分离，通过消息队列维护数据一致性。它天生就是为大规模分布式场景设计的，支持多副本、水平扩展、读写分离，可以把几十亿向量分散到多台机器上并行检索。这种架构在应对海量数据和高并发时优势明显，但代价是部署和运维复杂度显著提高。
一个形象的比喻：pgvector像是在一栋已经装修好的房子里加装了一间书房，水电管道都是现成的；Milvus则是专门为藏书百万册新建了一座图书馆，动线设计完全围绕藏书和检索，但建造和维护成本自然更高。
二、索引算法与检索性能对比
pgvector目前支持几种主流索引：IVFFlat、HNSW，以及较新版本的HalfVec和稀疏向量相关索引。HNSW是其中的主力，它在内存中构建多层图结构，查询时从顶层快速定位到目标区域再逐层下沉，精度和速度的平衡较好。IVFFlat则通过聚类把向量分桶，查询时只扫描部分桶，构建速度快、内存占用低，但精度对参数敏感。
Milvus支持的索引家族更丰富，包括IVF系列（IVF_FLAT、IVF_SQ8、IVF_PQ）、HNSW、DiskANN等，还提供GPU索引加速。更重要的是，Milvus支持标量量化（SQ）和乘积量化（PQ）压缩，能把向量压缩到原始大小的四分之一甚至更小，显著降低内存成本。DiskANN则让数据常驻SSD，适合内存放不下的大规模场景。
实际测试中，数据量在一千万以内时，两者的HNSW检索延迟差距并不悬殊，pgvector在百万级数据上单机表现相当不错。但当数据规模突破亿级、QPS达到数百以上时，pgvector单机架构的瓶颈就会暴露：内存放不下索引、无法水平扩展，而Milvus可以通过增加查询节点近乎线性地提升吞吐。下面是一段两者插入向量数据的代码对比，可以直观感受使用方式的差异。
-- PostgreSQL + pgvector：建表、建索引、检索一气呵成
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE documents (
id BIGSERIAL PRIMARY KEY,
content TEXT,
embedding vector(768)
);
-- 创建HNSW索引，向量距离使用内积
CREATE INDEX ON documents USING hnsw (embedding vector_ip_ops);
-- 向量检索加结构化过滤，一条SQL搞定
SELECT id, content
FROM documents
WHERE category = 'tech'
ORDER BY embedding <-> '[0.1, 0.2, 0.3, ...]'
LIMIT 10;
from pymilvus import MilvusClient, DataType
client = MilvusClient(uri="http://127.0.0.1:19530")
# 定义集合结构，显式声明向量维度和标量字段
schema = {
"fields": [
{"name": "id", "dtype": DataType.INT64, "is_primary": True},
{"name": "content", "dtype": DataType.VARCHAR, "max_length": 65535},
{"name": "embedding", "dtype": DataType.FLOAT_VECTOR, "dim": 768},
]
}
client.create_collection("documents", schema=schema, dimension=768)
# 检索时通过filter表达式做标量过滤
results = client.search(
collection_name="documents",
data=[[0.1, 0.2, 0.3]],
limit=10,
filter='category == "tech"',
output_fields=["content"]
)
三、功能特性：事务、过滤与生态
pgvector最大的优势在于完整继承了PostgreSQL的能力体系。向量字段和业务表天然支持ACID事务，你可以先插入业务数据再写入向量，两者在同一事务中要么同时成功要么同时回滚，数据一致性有根本保障。过滤查询方面，SQL的表达能力几乎无限：JOIN、聚合、窗口函数、全文检索都可以和向量检索组合，这在推荐系统、RAG知识库等需要复杂业务逻辑的场景里非常实用。
Milvus走的是另一条路。它提供标量字段和布尔表达式过滤，能力在持续增强，也能与Spark、Flink等大数据生态集成做离线导入。但它不具备传统意义上的多表事务，实体间的关联关系需要靠应用层维护。在数据更新方面，Milvus的删除和压缩机制相对复杂，频繁的增量更新需要关注compaction的性能开销；而PostgreSQL的更新删除就是普通的事务操作，心智负担小得多。
生态兼容性上，主流的AI框架如LangChain、LlamaIndex对两者都有良好支持，ORM层面SQLAlchemy配合pgvector也很成熟。如果你的技术栈本来就以PostgreSQL为核心，引入pgvector几乎是零学习成本；如果团队有专职运维且数据规模确实大，Milvus的分布式能力才值得投入。
四、运维成本与选型建议
运维维度上，pgvector就是运维一个PostgreSQL实例，备份恢复、主从复制、监控告警都是DBA熟悉的老套路，很多公司已有现成的PostgreSQL基础设施，加一个扩展就能跑起来。Milvus则依赖etcd、对象存储、消息队列等多个组件，生产环境通常还要上Kubernetes，运维门槛不低，中小团队如果没有专职人员，踩坑成本会很高。
给一个相对清晰的选型判断标准。满足以下条件时优先选pgvector：向量数据量在千万级以内、QPS压力中等、需要事务保障和复杂SQL过滤、团队已有PostgreSQL经验。而以下情况建议考虑Milvus：向量规模达到亿级以上、需要高并发低延迟检索、数据增长速度快需要水平扩展、有GPU或SSD加速需求、团队具备分布式系统运维能力。
还有一种务实的渐进式方案：项目初期用pgvector快速验证业务可行性，等数据量和流量真正逼近单机上限时再迁移到Milvus。由于两者的数据导入接口都比较清晰，提前把向量的生成和存储层做一层抽象，迁移的改造成本是可控的。技术上没有银弹，脱离实际数据规模和团队能力谈选型都是空谈，先量化你的真实负载，答案往往就清晰了。
PostgreSQLMilvus向量数据库修改时间：2026-09-04 15:40:43