向量检索已经成为PostgreSQL生态中最受关注的能力之一，尤其是RAG应用的兴起，让越来越多的团队直接把embedding存进数据库，而不是额外引入一个专用向量数据库。目前在PostgreSQL上做向量检索，最主流的选择有两个：一个是社区事实标准的pgvector，另一个是后起之秀pgvecto.rs。两者的定位相似，但底层设计差异相当大，选错了可能导致后面性能瓶颈和迁移成本都很高。本文从多个维度对这两个扩展做详细对比，帮助你根据业务实际情况做出判断。
一、基本架构与安装部署对比
pgvector是C语言编写的PostgreSQL扩展，完全遵循PostgreSQL的扩展机制，安装后通过CREATE EXTENSION vector启用，提供vector类型、<->等距离操作符和多种索引类型。它的最大特点是完全融入PostgreSQL的存储和事务体系，向量数据就存在普通的堆表里，MVCC、WAL、流复制、逻辑备份等机制对它全部透明生效。
pgvecto.rs则采用了完全不同的思路。它的核心计算部分用Rust编写，通过pgrx框架嵌入PostgreSQL进程，内部维护了一套独立的存储结构（类似一个嵌入式的向量引擎），而不是直接复用PostgreSQL的堆表存储。这种设计让它可以在索引组织和查询执行上做更激进的优化，比如更精细的内存管理、并行扫描和自定义的执行模型。
安装方面，pgvector编译依赖少，源码make install即可，各云厂商的托管PostgreSQL（如RDS、Supabase、阿里云RDS）几乎都原生支持。pgvecto.rs目前主要通过预编译包或Docker镜像分发，托管平台的支持范围明显更窄，如果团队使用的是云数据库，这一点需要提前确认。简单总结：pgvector开箱即用程度更高，pgvecto.rs更适合自建数据库的场景。
二、索引结构与查询性能对比
pgvector支持两种主流索引：IVFFlat和HNSW。IVFFlat是倒排文件索引，构建快、内存占用低，但召回率受lists和probes参数影响较大；HNSW是分层图索引，查询召回率高、性能稳定，但构建时间更长、内存占用更大。从0.5.0版本开始，HNSW还支持半精度存储来压缩内存。
下面是pgvector创建HNSW索引的典型写法：
-- 创建向量列 CREATE TABLE docs ( id bigserial PRIMARY KEY, content text, embedding vector(1536) ); -- 构建HNSW索引，使用余弦距离 CREATE INDEX ON docs USING hnsw (embedding vector_cosine_ops) WITH (m = 16, ef_construction = 64);
pgvecto.rs同样支持HNSW，并且在0.2版本之后默认采用了改进的索引结构和量化方案（如内置的SQ量化），官方基准测试中在高维向量、大规模数据集上的QPS和召回率表现普遍优于同期的pgvector。此外它对过滤查询做了专门优化，支持在索引层面直接带上过滤条件执行，避免pgvector中常见的先召回后过滤导致的召回率下降问题。
不过要注意，基准数据不能直接照搬。pgvecto.rs的性能优势在千万级以上向量、允许轻微召回损失的场景中最明显；在百万级以下的数据量上，两者差距往往在毫秒以内，此时pgvector的稳定性和生态兼容性反而更有价值。建议在正式选型前，用自己的真实数据和查询模式做一轮压测。
三、功能特性与生态兼容性
在功能层面，两者各有取舍。pgvector支持L2距离、内积和余弦距离三种度量，数组读写直接使用PostgreSQL原生接口，与pg_dump、pg_upgrade、逻辑复制等工具完全兼容。几乎所有主流ORM和框架（SQLAlchemy、Django、Prisma、LangChain、LlamaIndex）都内置了pgvector的适配。
pgvecto.rs支持的度量方式更多（包括Hamming、Jaccard等二值距离），查询语法上提供了独立的SELECT ... FROM vec_table风格接口和传统的操作符写法，还内置了标量量化、更好的并行写入能力。但由于它绕过了部分PostgreSQL存储机制，在一些工具链上存在限制，例如早期版本的逻辑复制兼容性、pg_upgrade大版本升级支持等，都需要在实际使用前仔细验证。
下面的表格概括了两者的核心差异：
| 对比项 | pgvector | pgvecto.rs |
|---|---|---|
| 实现语言 | C | Rust（基于pgrx） |
| 索引类型 | IVFFlat、HNSW | HNSW（含量化优化） |
| 云托管支持 | 广泛 | 有限 |
| 过滤查询优化 | 召回后过滤为主 | 索引层过滤 |
| 大版本升级 | 兼容pg_upgrade | 需验证迁移方案 |
四、选型建议与实践经验
如果你的数据量在千万级以内、业务对生态兼容性要求高（比如需要逻辑复制做灾备、依赖云托管数据库），pgvector是更稳妥的选择。它经过多年生产验证，社区活跃，遇到问题很容易找到案例。配合HNSW索引和合理的ef_search调参，绝大多数语义搜索场景都能拿到满意的结果。
如果你的向量规模上亿、写入吞吐大、查询QPS是核心瓶颈，或者需要重度使用过滤查询（比如带权限过滤的检索），pgvecto.rs值得投入。它的Rust实现带来了更好的内存安全性，索引层过滤在高选择性条件下优势明显。但要做好两点心理准备：一是托管环境支持有限，通常意味着自建和自运维；二是项目迭代速度快，版本升级可能伴随存储格式变更，需要制定数据迁移预案。
另一个务实的思路是分阶段演进：初期用pgvector快速上线，把精力放在embedding模型质量和召回效果调优上；当数据量和查询压力真正触顶、有实测数据支撑时，再评估是否迁移到pgvecto.rs或独立向量数据库。向量表的数据迁移本身并不复杂，导出embedding列重灌即可，真正要评估的是切换索引方案后的召回率回归和停机窗口。
总的来说，pgvector胜在稳定和生态，pgvecto.rs胜在性能上限和工程化设计。没有绝对的好坏，只有与业务规模、团队能力和运维条件是否匹配的区别。在动手之前，花一两天时间用真实数据做对比压测，得到的结论远比任何评测文章都可靠。
pgvectorpgvecto.rsPostgreSQL向量检索修改时间：2026-09-15 11:51:38