AI应用火了之后，向量数据库成了刚需，但很多团队其实并不想引入一套全新的基础设施。PostgreSQL作为老牌关系型数据库，通过向量扩展就能承担向量存储和相似度检索的任务，运维成本远低于单独部署一个专用向量库。目前社区里讨论最多的两个扩展是pgvector和pgvecto.rs（现已更名为VectorChord），它们看起来做的事差不多，实际架构和取舍却完全不同。这篇文章就把两者放在一起，从底层实现到实际使用逐项对比，看完你就能判断自己的项目该用哪个。
一、基本架构与底层实现的差异
pgvector是用C语言编写的PostgreSQL扩展，由Andrew Kane在2021年开源，目前是GitHub上star数最多的PG向量方案。它的核心思路是在PG原生的类型系统里增加一个vector类型，然后基于GiST和hnsw索引框架实现近似最近邻检索。由于深度整合了PostgreSQL的事务系统、WAL日志和MVCC机制，pgvector的行为和一个普通的PG扩展没有区别，备份恢复、流复制、主从切换这些既有运维体系可以原封不动地继承下来。
pgvecto.rs则走了另一条路，它用Rust编写（这也是名字里rs的由来），核心索引部分使用了Tantivy生态中的向量检索能力，通过pgrx框架嵌入PostgreSQL进程。它的索引不放在PG默认的表空间里，而是存储在独立的文件结构中，通过一个后台服务与SQL层交互。这种架构的好处是索引引擎可以自由演进，不受PG索引访问方法的接口限制，比如它可以实现更激进的量化压缩策略；代价则是引入了额外的运行组件，出问题时排查链路更长。
从哲学层面看，pgvector追求的是稳和兼容，尽量把自己做成PG的一部分；pgvecto.rs追求的是性能上限，愿意为此牺牲一些架构上的简单性。这个基调决定了后面所有维度的差异。
二、索引算法与查询能力对比
pgvector支持两种近似检索索引：IVFFlat和HNSW。IVFFlat实现简单、构建快、内存占用低，但召回率对参数（lists和probes）敏感，数据分布不均匀时表现不稳。HNSW是图索引，查询速度快、召回率高，是0.5.0版本之后官方主推的方案。pgvector支持L2距离、内积和余弦三种距离度量，覆盖了Embedding检索的绝大多数场景。
pgvecto.rs同样以HNSW为核心，但在此基础上做了不少工程优化。它支持SQ量化，可以在构建索引时对向量做有损压缩，显著降低内存占用，代价是召回率略有下降。它还提供了Hamming距离、Jaccard距离等度量方式，对某些二值特征或多模态检索场景更友好。另外pgvecto.rs在0.2版本后实现了部分索引扫描的并行化，在大规模数据集上的吞吐表现有优势。
下面是两者建索引和查询语法的直观对比。先看pgvector：
-- pgvector：建表并插入数据 CREATE TABLE items (id bigserial PRIMARY KEY, embedding vector(1536)); -- 建HNSW索引，指定余弦距离 CREATE INDEX ON items USING hnsw (embedding vector_cosine_ops); -- 相似度检索，按距离升序取前10条 SELECT id, embedding <=> '[0.1, 0.2, ...]' AS distance FROM items ORDER BY embedding <=> '[0.1, 0.2, ...]' LIMIT 10;
再看pgvecto.rs，它的语法风格明显不同：
-- pgvecto.rs：建表使用vecf16或vecf32类型 CREATE TABLE items (id bigserial PRIMARY KEY, embedding vecf32(1536)); -- 建索引，通过WITH子句指定量化选项 CREATE INDEX ON items USING vectors (embedding vecf32_cosine_ops) WITH (options = "[indexing.hnsw]");
查询时pgvecto.rs不用显式写ORDER BY，而是用一组操作符直接表达意图：
-- 按余弦距离检索最近的10条 SELECT id, embedding <-> '[0.1, 0.2, ...]' AS distance FROM items ORDER BY distance <-> '[0.1, 0.2, ...]' LIMIT 10; -- 实际推荐写法是操作符形式 SELECT id FROM items ORDER BY embedding <-> '[0.1, 0.2, ...]' LIMIT 10;
可以看到，pgvecto.rs的SQL接口抽象层级更高，牺牲了一些灵活性换取易用性；而pgvector的接口更贴近PG原生风格，SQL写法与普通查询保持一致，学习成本几乎为零。
三、性能表现与实际场景选型建议
在百万到千万级向量的典型测试中，两者大致呈现这样的规律：数据量较小（百万以内）时，两者查询延迟都在毫秒级，差距不明显；数据量上到千万级并且内存吃紧时，pgvecto.rs的SQ量化优势开始显现，内存占用可能只有pgvector HNSW的一半左右，配合并行扫描，QPS通常更高。但量化是有代价的，如果你的业务要求召回率在98%以上，pgvecto.rs可能需要关闭量化或调整参数，此时性能优势会缩小。
pgvector的性能短板主要在索引构建速度上。千万级向量的HNSW索引构建可能需要数小时，期间还会产生大量WAL日志，对主从复制有压力。应对办法是先在从库或新实例上建好索引，再通过逻辑复制或pg_dump迁移。pgvecto.rs的构建速度相对快一些，但由于索引存储在独立文件中，逻辑复制时索引不会被一起带过去，需要在新库重建。
选型上我给出几条比较明确的判断标准：
- 团队已经重度使用PG生态，希望零额外运维成本，数据量在千万级以内：优先pgvector，它的成熟度和社区支持无可替代，LangChain、LlamaIndex等框架对它的支持也最完善。
- 数据量超过千万、内存预算有限、对召回率要求在95%左右可接受：pgvecto.rs（VectorChord）的量化和并行能力更有优势。
- 需要复杂的混合查询（向量检索加多条件过滤）：两者都支持过滤，但pgvector与PG原生执行计划结合更好，过滤条件复杂时表现更稳。
- 对高可用、备份恢复有严格要求的金融类业务：pgvector更保险，它没有进程外的隐藏状态，任何PG备份工具都能完整覆盖。
还有一个容易被忽视的点：pgvecto.rs已经更名为VectorChord并调整了发展方向，选型时要关注项目的维护活跃度和迁移成本，避免绑定在一个变动频繁的版本线上。而pgvector背后有Supabase、Neon、Timescale等厂商的持续投入，长期维护风险相对更低。
总结来说，这不是一个非此即彼的问题。大多数中小规模的AI应用，pgvector加上HNSW索引就足够好用了；只有当数据规模和成本压力真正到来时，pgvecto.rs这类激进优化的方案才值得引入额外的复杂度。先用最简单的方案跑起来，等瓶颈出现了再演进，永远是最稳妥的工程决策。
pgvectorpgvecto.rs向量检索修改时间：2026-09-15 11:00:43