一家高速成长的电商初创公司的工程团队正在进行一场经典讨论。他们的推荐引擎需要语义搜索来将用户查询与数百万条商品描述匹配。他们该选择像 Qdrant 或 Pinecone 这样的专用向量数据库，还是使用 pgvector 把一切都留在 PostgreSQL 里？
这并非孤例。随着 AI 驱动的搜索与 RAG（Retrieval-Augmented Generation）系统在各行业成为标配，许多团队都在问同样的问题：
通用数据库是否真的能提供生产级的向量检索，还是 pgvector 被过度炒作了？
本文将拆解事实、基准测试与真实取舍，帮助你根据实际工作负载做出明智决策。
🚀 为什么 pgvector 会如此迅速走红
pgvector 是一个为 PostgreSQL 增加向量数据类型和相似度搜索的开源扩展。其吸引力很直接：
-
无需维护额外的数据库 -
关系型 + 向量数据都在一个地方 -
ACID 保证也适用于向量 -
复用已有的 PostgreSQL 生态（备份、HA、监控） -
用 SQL 将结构化过滤与语义搜索组合
对于已经深度使用 PostgreSQL 的团队来说，运维简单是巨大优势。
一个实际示例： 某客服平台可以在一次查询中同时检索相关帮助文章和用户账户信息。若使用两个独立数据库，这在运维上会变得昂贵。
⚡ 性能改进：哪些是真的，哪些不是
过去两年，pgvector 的性能显著提升——尤其是在引入 HNSW 索引（v0.5+）之后。
✔ 确实改进的方面：
-
索引构建相比旧版本更快 -
更低延迟下能获得更高召回率 -
HNSW 无需训练步骤（不同于 IVFFlat） -
并行查询性能更好 -
召回率与延迟的权衡更可预测
✔ 基准测试普遍显示：
pgvector 在以下场景表现良好：
-
数据集规模低于约 5000 万向量 -
同时包含关系型过滤与向量检索的混合负载 -
需要运维简单性的部署
✔ 并非普适的结论：
-
在纯向量检索上，pgvector 并不比 Qdrant、Milvus 或 Pinecone 更快 -
pgvector 并未针对十亿级嵌入做优化 -
在复杂多维过滤下，pgvector 不保证快速的 ANN -
在高吞吐条件下，pgvector 并不能稳定提供低于 10ms 的延迟
用 Rust/C++ 编写的向量数据库在高性能场景中仍然占优。
🧩 生产环境的现实：优势与局限
1️⃣ 带过滤的搜索：pgvector 的薄弱点
带过滤的向量搜索很常见（例如：“查找相似商品，且 status = active”）。PostgreSQL 通常先执行 ANN，再应用过滤。这往往导致：
-
结果缺失 -
召回不稳定 -
大数据集上的过滤更慢
专用向量数据库原生支持 带过滤的 ANN。
pgvector 的迭代扫描有所帮助，但并不能彻底解决问题。
2️⃣ 内存需求远超预期
HNSW 索引在任何平台上都很“吃内存”，不仅限于 Postgres。
但 PostgreSQL 还存在这些约束：
-
没有索引节流机制 -
WAL 活动量大 -
内存不足时整体变慢
大型数据集很容易需要 数百 GB 的内存。
3️⃣ 索引构建耗时且吃资源
索引构建会：
-
消耗大量 maintenance_work_mem -
可能阻塞其他负载 -
对于上千万向量，耗时以小时计
而向量数据库通常提供：
-
分布式索引构建 -
后台优化器 -
磁盘持久化的图结构
4️⃣ 高速摄取并非 PostgreSQL 所长
嵌入的实时摄取会暴露瓶颈：
-
WAL 开销 -
HNSW 增量更新较慢 -
写放大
PostgreSQL 从一开始就不是为高吞吐向量摄取而设计的。
🌟 pgvector 表现极佳的场景
✔ 推荐系统
在 SQL 中同时结合向量相似度与商品元数据是巨大优势。
✔ RAG（Retrieval-Augmented Generation）
大多数真实的 RAG 流水线嵌入量低于千万级。
pgvector 具备竞争力并能简化架构。
✔ 文档、Wiki、知识库的语义搜索
企业知识库、内部 Wiki、产品文档都是理想工作负载。
🏗 pgvector 的边界
❌ 超过 5000–1 亿向量的数据集
内存和索引构建时间会成为主要问题。
❌ 需要过滤后保证返回 k 个结果的负载
pgvector 目前仍难以高效保证这一点。
❌ 需要持续的超低延迟（<10ms）
基于 Rust/C++ 的向量引擎整体表现更优。
🔧 实用的决策框架
✅ 在以下情况下选择 pgvector：
-
你已在生产中使用 PostgreSQL -
数据集 < 5000 万向量 -
需要将向量检索与关系型过滤结合 -
需要 ACID 保证 -
预算敏感 -
运维简单是优先级
🔥 在以下情况下选择 Qdrant / Pinecone / Milvus / Weaviate：
-
向量检索是核心工作负载 -
需要稳定的 <10ms 延迟 -
数据集规模为 1 亿–10 亿级+ -
需要多过滤条件下的 ANN -
需要水平扩展
🔄 混合架构
用 PostgreSQL 存元数据，用向量数据库做向量检索。
很多团队都采用这种模式。
🧪 基准测试真正告诉我们的是什么
基准结果之所以差异巨大，是因为：
-
数据集规模 -
召回目标 -
向量维度 -
过滤模式 -
硬件 -
索引参数
……都会显著影响结果。
不存在通用赢家。
正确的选择取决于你的工作负载，而不是某一张基准图表。
🛠 实现示例：基于 pgvector 的文档搜索系统
CREATE EXTENSION vector;
CREATE TABLE documents (
id SERIAL PRIMARY KEY,
title TEXT NOT NULL,
content TEXT NOT NULL,
category VARCHAR(50),
created_at TIMESTAMPDEFAULTCURRENT_TIMESTAMP,
embedding vector(1536)
);
CREATE INDEX ON documents
USING hnsw (embedding vector_cosine_ops)
WITH (m =16, ef_construction =64);
CREATE INDEX ON documents(category);
CREATE INDEX ON documents(created_at);
带过滤的语义搜索：
SELECT
id,
title,
1 - (embedding <=> '[0.15, 0.18, ...]'::vector) AS similarity
FROM documents
WHERE category = 'technology'
ORDER BY embedding <=> '[0.15, 0.18, ...]'::vector
LIMIT 10;
🧵 Python 集成示例
response = client.embeddings.create(
model="text-embedding-ada-002",
input=query
)
（示例为适配 Medium 可读性而做了简化。）
🎯 最终结论：成熟、好用，但不是灵丹妙药
pgvector 已从实验性扩展成长为许多 AI 工作负载的可靠生产选项。
但它并不能普遍替代专用向量数据库。
现实是：
-
对小到中等规模的向量数据集，pgvector 非常优秀 -
当需要将 SQL 过滤与语义搜索结合时，pgvector 非常理想 -
对超大规模数据集或超低延迟场景，pgvector 并非最佳 -
在高规模场景下，向量数据库依然更“能打”
热潮褪去后，留下的是一个非常务实、非常好用、适配大量真实工作负载的工具。
📚 参考资料
-
pgvector GitHub - https://github.com/pgvector/pgvector -
Crunchy Data - Performance Tips Using Postgres and pgvector -
Jonathan Katz - pgvector Performance Improvements -
Timescale - pgvector vs Qdrant Benchmarks -
Qdrant Docs - Filtering & ANN performance -
Azure - pgvector performance optimization -
Google Cloud - Similarity search with pgvector