pgvector 生产实战：当 PostgreSQL 顶替专用向量数据库，什么时侯顶不住

每个搭 RAG 流水线或语义搜索的团队迟早都会问同一个问题：要专门搞一个向量数据库吗，还是把 embedding 直接塞进已有的那个数据库？2026 年 7 月 BigData Boutique 发表的这篇实战总结给出了一个相当”反直觉”的答案——在大多数生产负载下，PostgreSQL + pgvector 扩展就够了。本文小夏把它译成中文，整理出关键决策点和参数建议，帮你判断你这边是不是该翻车。

1. pgvector 到底给了你什么

pgvector 是 PostgreSQL 的扩展，给标准 PG 实例（13+；0.8.0 起不再支持 12）加上向量数据类型和近似最近邻（ANN）搜索能力。把 embedding 存到一列、给那列建索引、用普通 SQL 写距离算子查询就行——没有第二个服务、没有第二套一致性模型、没有第二个备份对象。

扩展本身提供几种列类型。核心的 vector 类型存单精度浮点，最多支持 16,000 维存储但索引上限 2,000 维。要索引更高维的 embedding，pgvector 0.7.0（2024 年 4 月）加了 halfvec 半精度类型，索引上限提到 4,000 维，索引大小直接砍一半。还有 sparsevec 存稀疏向量、bit 存二进制向量用于二进制量化。距离算子对应：<-> L2 / 欧氏、<=> 余弦、<#> 负内积、<+> L1；bit 用 <~>（Hamming）和 <%>（Jaccard）。

最小端到端的样子：

CREATE EXTENSION vector;

CREATE TABLE documents (
    id        bigserial PRIMARY KEY,
    tenant_id int,
    body      text,
    embedding vector(1536)
);

-- HNSW index with cosine distance
CREATE INDEX ON documents
    USING hnsw (embedding vector_cosine_ops)
    WITH (m = 16, ef_construction = 64);

-- nearest neighbor query
SELECT id, body
FROM documents
ORDER BY embedding <=> '[0.012, -0.43, ...]'
LIMIT 10;

索引的 operator class（vector_cosine_ops / vector_l2_ops / vector_ip_ops 或 halfvec_*）必须跟查询算子匹配——按 cosine 建索引、用 <=> 查询，错配的话 planner 会静默退化成顺序扫描。这是”pgvector 慢”投诉里最常见的原因，没有之一。

2. HNSW vs IVFFlat：HNSW 是默认选择

pgvector 提供两种 ANN 索引，怎么选基本已经定下来了。HNSW 在 0.5.0（2023 年 8 月）加入，让扩展第一次走出 demo 可用。IVFFlat 更早出现。

HNSW建一个多层近邻图。它的 recall-vs-latency 曲线比 IVFFlat 好，但建索引慢、耗内存；建索引不需要训练集，可以空表起建、随数据进来增量填充。IVFFlat把向量分成 lists 个聚类、查询时只探测其中一部分；建索引快、省内存，但必须（or 重新）用代表性数据选好聚类中心，数据漂移后 recall 会下降。

维度	HNSW	IVFFlat
低延迟高 recall	更优	较弱
建索引速度	较慢	较快
内存占用	较高	较低
建索引是否需要训练	否	是（要聚类中心）
增量插入	友好	漂移，要重建
关键建索引参数	m, ef_construction	lists
关键查询参数	hnsw.ef_search	ivfflat.probes

大多数生产 RAG 和语义搜索，HNSW 是默认选项；只有当存储问题倒逼、且能接受 recall 下降时再用 IVFFlat。详细算法取舍见《HNSW vs IVFFlat: How to Choose the Right Vector Index》。

3. 调 recall 和 latency：3 个最关键的旋钮

ANN 搜索的本质是用精确度换速度，调参就是决定愿意放弃多少 recall。pgvector 把这些旋钮分成建索引阶段和查询阶段两类。

HNSW 三个：m（默认 16）是图里每个节点的连接数，调高 recall 更好但索引更大、建索引更慢；ef_construction（默认 64）是建索引时的候选列表大小，调高图更好但建索引更慢；hnsw.ef_search（默认 40）是查询时的候选列表大小，是运行时最重要的旋钮：

SET hnsw.ef_search = 100;

SELECT id FROM documents
ORDER BY embedding <=> '[0.012, -0.43, ...]'
LIMIT 10;

调高 ef_search，recall 和 latency 一起涨——这是一个不用重建索引就能拨的查询时旋钮。IVFFlat 的等价旋钮是 ivfflat.probes（探测列表数），对应建索引时的 lists 数。README给的建议：百万行以下 lists = rows / 1000，百万行以上 sqrt(rows)；probes 从 sqrt(lists) 起调直到 recall 达标。

ANN 的 recall 是”最近邻里实际返回的比例”——recall 0.95 就是 100 个最近邻里返回 89 个。调参本质就是用 latency 和内存换 recall，然后停在满足质量要求的最便宜那点。

两个反直觉的坑：(1) 给大表建 HNSW 时 maintenance_work_mem 不能太小，否则建索引会 spill 到磁盘慢到令人发指；(2) 别在 1 万行小数据集上 benchmark 然后上线——生产规模下 recall 会塌，用生产规模数据上的 held-out 查询集测 recall。

4. 0.8.x 的拐点：过滤搜索 + 量化

生产向量搜索真正的难题不是纯最近邻查找，而是带过滤的搜索——”给这个租户、这段时间范围内的最近文档”。朴素做法是先按 ANN 取 top-K 再加 WHERE 过滤，结果多数被过滤掉，请求 10 条可能就返回 2 条。这是 pgvector 多年来最尖锐的痛点，叫”overfiltering”。

pgvector 0.8.0（2024 年 10 月）带来了 iterative index scans：过滤查询返回行数不够时，索引会持续扫描直到凑够行数，受 hnsw.iterative_scan（off / strict_order / relaxed_order）控制，上限 hnsw.max_scan_tuples（默认 20,000，真正会撞到的那条），hnsw.scan_mem_multiplier 控制内存上限。IVFFlat 也有等价机制。同一版本还改善了代价模型，让 planner 在过滤选择性高时更倾向走普通 B-tree 索引而非向量索引。

0.8.1（2025 年 9 月，支持 PG 18）到 0.8.6（2026 年 7 月）都是稳定性修复——HNSW vacuuming、index corruption、并行构建的 buffer overflow、小表内存量。还在 0.8.3 以下就先升级，先升再调。

AWS 在 Aurora PostgreSQL 上发了一组 pgvector 0.8.0 的 benchmark 数据能说明 iterative scan 的价值：1000 万产品 / 384 维 embedding 的数据集，过滤查询的”结果完整度”从 0.7.4 的最低 1% 升到 100%；top-10 p99 latency 从 123.3 ms 降到 ef_search=40 + relaxed_order 下的 13.1 ms；top-1000 改进小得多（104.2 → 83.5 ms）。这是 vendor 数据、对自己工作有利，当方向看别当承诺。

量化的方向：halfvec 半精度直接把索引大小砍一半，recall 损失通常可以忽略，是性价比最高的省内存手段；binary_quantize() 把 embedding 压成 bit 走 <~>，适合超大规模用”粗筛 + 全精度重排”的两阶段架构。底层机制见《What is a Vector Database》。

5. pgvector 的临界点：什么时候该让位

临界点是 RAM。HNSW 只在索引完全驻内存时才有好 latency，算术很简单：1536 维 float32 embedding 大约 6 KB，1000 万向量大约 60 GB（加图开销），用 halfvec 能砍到约 30 GB——能装进一台大内存 PG；1 亿装不下，一旦索引页开始换页，latency 就断崖下跌。1000 万这个量级的建索引，m=16 下也得跑几小时（除非 maintenance_work_mem 给足），每次重建都同样代价。

RAM 线之下用 pgvector 是对的：当你已经在用 PostgreSQL、想要一份运维（一份备份、一份复制、一份权限、一份事务一致性）、读多写少、能用关系数据 join 向量数据。多租户 SaaS 是典型场景，模式是按 tenant_id 做分区或 partial index，让每次查询只碰一个小索引：

-- 每个大租户一个小 HNSW
CREATE INDEX ON documents
    USING hnsw (embedding vector_cosine_ops)
    WHERE tenant_id = 42;

-- 或直接按 tenant 分区
CREATE TABLE documents (...) PARTITION BY LIST (tenant_id);

到千万到亿级就该迁专用向量库了——它们原生支持分片、内存分层、保 tail latency 平稳，相关讨论见《Scaling vector search from millions to billions》。以下三种场景也该让位：(1) 要做大规模 BM25 + dense 的混合搜索；(2) 写入超量程（每秒上千次插入/更新），HNSW 上会拖 VACUUM、累积 dead tuple、索引膨胀；(3) 大型密集索引的多 region 复制，本质是同一类难题在扩散。

因素	pgvector（PostgreSQL）	专用向量库（Pinecone / Qdrant / OpenSearch）
语料甜点	≤ 1000 万向量（能装进 RAM）	1000 万到 10 亿
运维负担	复用现有 Postgres	要新学一套服务
与关系数据的事务一致性	原生	外部/最终
过滤 + 多租户搜索	强（0.8.0+）	强
大规模 BM25 + 向量	有限	一等公民（OpenSearch）
索引横向扩展	手动 / 有限	原生分片
高写入压力	索引维护压力大	为这种场景设计

被忽略最多的一种方案是拆出去：metadata / 权限 / 业务真相留在 PostgreSQL，只有密集索引下放到专用引擎。文档和 embedding 不必非住在同一个库里——Postgres 还是 system of record，CDC 或 batch job 把 embedding 推到那边，应用层用 ID join 回去。你放弃两个库之间的事务一致性，但留下 Postgres 原来给你的所有好处。整体数据架构决策见《How to Choose a Database for Your Next Project》；专用选项横向对比见《Vector Database Comparison 2026》。

小夏点评

看完这篇实战总结，小夏感受最深的三点：

1. “能用现有库就别加新组件” 这条工程纪律今天依然成立。pgvector 0.8.x 把”千万级以下”这个甜点做得非常稳，运维单一性、事务一致性、备份简化这些隐性价值远大于”专门搞个向量库”听起来的高级感。先用现有 PG 跑通业务，跑不动了再谈换。
2. 算术比”指标”更值得看。网上所有”专用向量库比 PG 快 N 倍”的 benchmark 都是对自己工作有利的；真到生产你要算的是 1000 万 × 6 KB = 60 GB 这个基础算式，能装进 RAM 就是好的，装不下就认。这是采购决策里最该自己算的一道。
3. 0.8.0 的 iterative_scan 是分水岭。overfiltering 是 pgvector 多年来的硬伤，过滤查询在生产语义搜索里几乎是标配。如果团队还在用 0.7.x，升级带来的过滤查询改进比”换向量库”性价比高得多。

对中国 IT 运维者的启示：(1) 已经在跑 PostgreSQL 的，2026 年值得花一天升级到 pgvector 0.8.3+，把过滤查询能力拿到手；(2) 千万级以下的 RAG / 语义搜索不要再被 vendor 号向量库说服，把 RAM 算清楚先；(3) 真到亿级，拆出去是比”全栈换引擎”更便宜的方案——Postgres 留作 system of record，密集索引下放到专用引擎，CDC 串起来。

参考链接

• pgvector in Production: When PostgreSQL Replaces a Dedicated Vector Database | BigData Boutique
• pgvector / pgvector on GitHub
• pgvector CHANGELOG
• pgvector 0.8.0 发布说明
• AWS Database Blog: Supercharging vector search with pgvector 0.8.0
• HNSW vs IVFFlat: How to Choose the Right Vector Index
• What is a Vector Database
• Scaling vector search from millions to billions
• How to Choose a Database for Your Next Project
• Vector Database Comparison 2026