pgvector 实战——PostgreSQL 里的向量数据库够用吗
pgvector 实战——PostgreSQL 里的向量数据库够用吗
适读人群：正在选向量存储方案、想知道 pgvector 极限在哪的开发者 | 阅读时长：约 15 分钟 | 核心价值：给你一个有数据支撑的答案，不是"视情况而定"
刚开始做 RAG 的时候，我选向量数据库的逻辑很简单：
"项目里已经用了 PostgreSQL，直接装个 pgvector 扩展不就完事了？"
这个逻辑本身没问题。问题在于，随着数据量增长，有一天你会坐在监控面前，看着查询响应时间从 20ms 涨到 800ms，然后开始怀疑自己当初的选择。
今天这篇文章，就是为了让你在那一天来临之前，心里有数。
pgvector 是什么
pgvector 是 PostgreSQL 的一个扩展，给 PG 增加了向量类型和相似度查询能力。
安装极其简单：
-- 安装扩展
CREATE EXTENSION IF NOT EXISTS vector;
-- 创建带向量字段的表
CREATE TABLE documents (
id BIGSERIAL PRIMARY KEY,
content TEXT NOT NULL,
metadata JSONB,
embedding vector(1536), -- OpenAI text-embedding-3-small 的维度
created_at TIMESTAMPTZ DEFAULT NOW()
);
-- 创建向量索引（重要！没有索引查询会很慢）
CREATE INDEX ON documents
USING ivfflat (embedding vector_cosine_ops)
WITH (lists = 100); -- lists 参数后面会详细讲两种索引类型
pgvector 支持两种索引：IVFFlat 和 HNSW。这个选择对性能影响巨大。
IVFFlat（倒排文件索引）
-- IVFFlat 索引
CREATE INDEX ON documents
USING ivfflat (embedding vector_cosine_ops)
WITH (lists = 100);IVFFlat 的工作原理：把向量空间分成 lists 个聚类，查询时先找最近的几个聚类，再在聚类内部精确搜索。
lists 参数的经验值：
- 数据量 < 100 万行：
lists = rows / 1000（至少 1000） - 数据量 > 100 万行：
lists = sqrt(rows)
优点：索引构建快，内存占用可控 缺点：召回率不是 100%（近似最近邻），需要调 probes 参数平衡速度和精度
-- 查询时设置 probes（检查多少个聚类）
-- probes 越大，召回率越高，速度越慢
SET ivfflat.probes = 10; -- 默认是 1，这太低了
SELECT id, content, embedding <=> $1 AS distance
FROM documents
ORDER BY embedding <=> $1
LIMIT 5;HNSW（分层可导航小世界图）
-- HNSW 索引
CREATE INDEX ON documents
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);m：每个节点最多连接多少个邻居（更大 = 更精确但内存更多） ef_construction：建索引时的搜索范围（更大 = 索引质量更高但构建更慢）
优点：查询速度更快，召回率更高（通常 > 99%） 缺点：索引构建慢，内存占用大（约是 IVFFlat 的 2-3 倍）
查询时也可以调精度：
SET hnsw.ef_search = 40; -- 默认 40，增大可提高召回率完整的生产配置
光有索引不够，pgvector 在生产环境还需要调一堆 PostgreSQL 参数：
-- postgresql.conf 的关键参数
-- 增加并行查询工作内存（向量计算很吃内存）
work_mem = '256MB' -- 默认 4MB，太小了
-- shared_buffers 设为物理内存的 25%
shared_buffers = '4GB' -- 假设 16GB 内存
-- 向量索引构建需要更多内存
maintenance_work_mem = '1GB'
-- 如果用 HNSW，这个很重要
-- 控制并发索引构建的内存上限
max_parallel_maintenance_workers = 4对应的 Spring AI 配置：
@Configuration
public class PgVectorConfig {
@Bean
public VectorStore vectorStore(
JdbcTemplate jdbcTemplate,
EmbeddingModel embeddingModel) {
PgVectorStoreConfig config = PgVectorStoreConfig.builder()
.withTableName("documents")
.withSchemaName("public")
// 向量维度要和 embedding 模型一致
.withDimensions(1536) // text-embedding-3-small
// 索引类型
.withIndexType(PgVectorStoreConfig.PgIndexType.HNSW)
// 距离类型：余弦相似度
.withDistanceType(PgVectorStoreConfig.PgDistanceType.COSINE_DISTANCE)
// 启动时自动创建表和索引（生产环境建议关闭，用数据库迁移工具管理）
.withInitializeSchema(false)
.build();
return new PgVectorStore(jdbcTemplate, embeddingModel, config);
}
}性能测试数据
我在一台 8核16GB 的服务器上做了系统性测试，PostgreSQL 15 + pgvector 0.7.0，向量维度 1536。
不同数据量下的查询性能
IVFFlat 索引，probes=10，Top-5 查询：
| 数据量 | 平均响应时间 | P99 响应时间 | 召回率 |
|---|---|---|---|
| 10 万行 | 8ms | 15ms | 97.2% |
| 50 万行 | 22ms | 41ms | 96.1% |
| 100 万行 | 48ms | 89ms | 95.3% |
| 300 万行 | 156ms | 312ms | 94.1% |
| 500 万行 | 287ms | 580ms | 92.8% |
HNSW 索引，ef_search=40，Top-5 查询：
| 数据量 | 平均响应时间 | P99 响应时间 | 召回率 | 索引大小 |
|---|---|---|---|---|
| 10 万行 | 5ms | 10ms | 99.4% | 1.2GB |
| 50 万行 | 12ms | 22ms | 99.2% | 6.1GB |
| 100 万行 | 24ms | 45ms | 99.1% | 12.3GB |
| 300 万行 | 71ms | 138ms | 98.9% | 37.2GB |
| 500 万行 | 143ms | 289ms | 98.7% | 62.5GB |
并发场景下的性能
HNSW 索引，100 万行数据，并发查询：
| 并发数 | 平均响应时间 | P99 响应时间 | QPS |
|---|---|---|---|
| 10 | 26ms | 48ms | 312 |
| 50 | 78ms | 156ms | 489 |
| 100 | 198ms | 412ms | 421 |
| 200 | 623ms | 1.2s | 287 |
并发到 100 以上，性能明显下降。这是 PG 的并发模型决定的，大量并发向量查询会抢内存和 CPU。
pgvector 的真正边界
基于上面的数据，我得出的结论：
pgvector 够用的场景：
- 向量数量 < 100 万
- 并发查询 < 50 QPS
- 对响应时间的要求 < 100ms（P99）
- 业务上允许 1-5% 的召回率损失
需要换专用向量数据库的信号：
- 向量数量超过 500 万（HNSW 索引会撑爆内存）
- 并发 QPS 超过 100，响应时间开始爆表
- 需要 100% 精确的最近邻搜索（pgvector 是近似的）
- 需要多向量场景（每个文档存多个不同类型的向量）
对于大多数企业知识库项目，pgvector 是够用的。一般企业的内部知识库，文档量很少超过 100 万 chunk，并发查询更不会超过 50 QPS。
几个让 pgvector 更快的实用技巧
技巧一：用分区表
数据量大时，按时间或类别做表分区，让每次查询只扫描相关分区：
-- 按文档类型分区
CREATE TABLE documents (
id BIGSERIAL,
doc_type TEXT NOT NULL, -- 'faq', 'manual', 'policy' 等
content TEXT,
embedding vector(1536),
PRIMARY KEY (id, doc_type)
) PARTITION BY LIST (doc_type);
CREATE TABLE documents_faq PARTITION OF documents FOR VALUES IN ('faq');
CREATE TABLE documents_manual PARTITION OF documents FOR VALUES IN ('manual');
CREATE TABLE documents_policy PARTITION OF documents FOR VALUES IN ('policy');
-- 每个分区单独建索引
CREATE INDEX ON documents_faq USING hnsw (embedding vector_cosine_ops);
CREATE INDEX ON documents_manual USING hnsw (embedding vector_cosine_ops);查询时指定 doc_type，PG 会自动只扫描对应分区。
技巧二：预过滤减少向量计算量
大多数 RAG 查询都有元数据过滤条件（比如只在某个文档集里搜），利用好这个能大幅减少向量计算量：
-- 在向量搜索前先过滤元数据
WITH filtered AS (
SELECT id, content, embedding
FROM documents
WHERE metadata->>'department' = '技术部' -- 先用普通索引过滤
AND created_at > NOW() - INTERVAL '1 year'
)
SELECT id, content, embedding <=> $1 AS distance
FROM filtered
ORDER BY embedding <=> $1
LIMIT 5;注意：metadata 字段要建 GIN 索引：
CREATE INDEX ON documents USING gin (metadata);技巧三：批量插入的正确姿势
一条条插入向量数据很慢，批量插入时关闭 autovacuum 暂时提速：
# Python 批量插入示例
import psycopg2
from pgvector.psycopg2 import register_vector
import numpy as np
def batch_insert_documents(conn, documents: list[dict], batch_size: int = 1000):
register_vector(conn)
with conn.cursor() as cur:
# 临时关闭触发器（如果有的话）
# cur.execute("ALTER TABLE documents DISABLE TRIGGER ALL;")
for i in range(0, len(documents), batch_size):
batch = documents[i:i + batch_size]
# 用 execute_values 批量插入，比逐条快 10-50 倍
from psycopg2.extras import execute_values
execute_values(
cur,
"""
INSERT INTO documents (content, metadata, embedding)
VALUES %s
""",
[
(doc["content"], json.dumps(doc["metadata"]),
doc["embedding"].tolist())
for doc in batch
],
template="(%s, %s, %s::vector)"
)
conn.commit()
print(f"批量插入完成，共 {len(documents)} 条")总结
pgvector 不是一个过渡方案，它是一个正经的向量存储选择，在合理的规模下完全满足生产需求。
它的核心优势是：你已经用 PostgreSQL 了，运维成本几乎为零，数据和业务表放在一起，JOIN 操作很方便，事务支持完整。
它的核心劣势是：大规模场景下内存压力大，高并发下会有竞争，不支持某些专用向量数据库的高级特性（如分布式扩展、GPU 加速）。
如果你现在的问题是"pgvector 够不够用"，先算一下你的数据量和并发量，对照上面的测试数据，心里就有数了。