PostgreSQL向量检索实战解析：生产级应用还是技术炒作？

一家电商初创公司的工程团队正面临一个典型的技术选型难题。他们的推荐系统需要实现语义搜索，以匹配用户查询与海量商品描述。团队的核心争议在于：是选择 Qdrant 或 Pinecone 这类专用向量数据库，还是采用 pgvector 扩展，将所有数据保留在 PostgreSQL 中？

这并非个例。随着 AI 驱动的搜索与 RAG（检索增强生成）系统在各行业普及，许多技术团队都在思考同一个问题：

通用数据库能否胜任生产级的向量检索，还是说 pgvector 的热度被高估了？

本文将通过剖析技术事实、基准测试结果与实际应用中的权衡，帮助你根据具体的工作负载做出明智决策。

🚀 pgvector 迅速流行的原因

pgvector 是一个为 PostgreSQL 增加向量数据类型和相似度搜索能力的开源扩展。其吸引力显而易见：

简化运维：无需引入和维护额外的数据库系统。
数据统一：关系型数据与向量数据共存于同一数据库，简化了数据一致性管理。
事务保证：向量操作同样享有 PostgreSQL 的 ACID 事务特性。
生态复用：可直接利用现有的 PostgreSQL 高可用、备份、监控等成熟工具链。
查询灵活：使用标准 SQL 即可无缝结合结构化过滤与语义搜索。

对于已深度依赖 PostgreSQL 的团队而言，运维的简化是巨大的优势。

一个典型场景：某客服平台可以在单次查询中，同时检索相关的帮助文档和对应的用户账户信息。若使用两个独立的数据库，实现相同功能在运维和数据同步上会复杂得多。

⚡ 性能演进：真实的进步与局限

过去两年，pgvector 的性能取得了显著提升，尤其是在引入 HNSW 索引（v0.5+ 版本）之后。

✔ 已证实的改进：

索引构建速度：相比早期版本大幅提升。
效率与召回：在相同延迟下能获得更高的召回率。
索引便捷性：HNSW 索引无需像 IVFFlat 那样进行预训练。
并行查询：并行处理能力得到优化。
可预测性：召回率与延迟之间的权衡关系更加可控和可预测。

✔ 基准测试的普遍共识：

pgvector 在以下场景表现良好：

数据规模：向量数量通常在 5000 万以下。
混合负载：查询同时包含关系型条件过滤和向量相似度检索。
运维优先：团队更看重架构的简单性和运维的便利性。

✔ 需要澄清的误区：

纯向量检索速度：在纯粹的向量最近邻搜索上，pgvector 通常不敌 Qdrant、Milvus 或 Pinecone 等专用数据库。
超大规模优化：其架构并非为十亿级别的向量数据集进行过深度优化。
复杂过滤下的 ANN：在结合复杂多维过滤条件时，无法保证高效的近似最近邻搜索性能。
极致延迟：在高吞吐量场景下，难以持续稳定地提供低于 10 毫秒的查询延迟。

采用 Rust/C++ 等语言编写的专用向量数据库，在高性能、高并发场景中依然保持优势。

🧩 生产环境审视：优势与挑战

1️⃣ 带过滤的向量搜索：当前的短板

结合过滤条件的向量搜索非常普遍（例如：“查找相似商品，且状态为‘在售’”）。PostgreSQL 的典型执行计划是先进行近似最近邻搜索，再应用过滤条件，这可能导致：

结果遗漏：过滤后返回的结果数量可能少于请求的数量。
召回率波动：在不同查询条件下，召回率可能不稳定。
性能下降：在大数据集上，后过滤（post-filtering）会显著增加开销。

专用向量数据库通常原生支持 带过滤条件的近似最近邻搜索。虽然 pgvector 通过迭代扫描等方式进行了改进，但尚未从根本上解决此问题。

2️⃣ 内存消耗可能超出预估

HNSW 索引本身在任何系统中都是内存消耗大户。而在 PostgreSQL 环境中，还需考虑以下额外因素：

缺乏节流：PostgreSQL 没有为向量索引构建提供专门的资源节流机制。
WAL 开销：向量数据的写入会产生大量的预写日志，增加 I/O 压力。
系统级影响：当内存不足时，会影响整个数据库实例的性能。

处理大型向量数据集时，很容易需要 数百 GB 甚至更高的内存配置。

3️⃣ 索引构建耗时且资源密集

创建 HNSW 索引是一个资源密集型操作：

内存占用高：会大量消耗 maintenance_work_mem 配置的内存。
可能阻塞操作：大型索引构建期间可能影响其他读写操作。
构建时间长：对于数千万量级的向量，构建时间可能长达数小时。

相比之下，许多专用向量数据库提供了更优的解决方案：
* 分布式构建：支持跨节点并行构建索引。
* 后台优化：索引优化可在后台异步进行。
* 持久化存储：索引结构针对磁盘持久化进行了优化。

4️⃣ 高吞吐写入并非其设计强项

实时、高吞吐量的向量数据摄入会暴露 PostgreSQL 的瓶颈：

WAL 压力：每次写入都伴随 WAL 日志记录，成为潜在的 I/O 瓶颈。
增量更新效率：HNSW 索引的增量更新效率相对较低。
写放大：可能导致显著的写放大现象。

PostgreSQL 的核心设计初衷并非针对高吞吐的向量数据流式写入。

🌟 pgvector 的优势应用场景

✔ 推荐系统

能够在一个 SQL 查询中，灵活地结合用户/商品画像（关系数据）与嵌入向量（语义相似度），是 pgvector 的突出优势。

✔ RAG（检索增强生成）

大多数实际应用的 RAG 流水线，其知识库的嵌入向量总量在千万级以下。pgvector 在此规模下具备竞争力，并能显著简化系统架构。

✔ 文档与知识库语义搜索

企业内部 Wiki、产品文档库、客户支持知识库等场景，其数据量和查询模式通常与 pgvector 的能力非常匹配。

🏗 pgvector 的能力边界

❌ 超大规模数据集（超过 5000 万至 1 亿向量）

内存需求和索引构建时间将成为主要制约因素。

❌ 需要“过滤后保证返回 K 个结果”的严格场景

pgvector 目前难以高效、稳定地满足此类需求。

❌ 对延迟有极端要求的场景（持续低于 10 毫秒）

基于 Rust/C++ 构建的专用向量引擎在此类场景下整体表现更优。

🔧 实用的技术选型框架

✅ 在以下情况下，优先考虑 pgvector：

你的生产环境已重度使用 PostgreSQL。
向量数据集规模小于 5000 万。
查询需要频繁结合关系型过滤与向量检索。
业务逻辑需要完整的 ACID 事务保证。
预算有限，希望控制基础设施复杂度与成本。
团队运维简单性是高优先级考量。

🔥 在以下情况下，应考虑 Qdrant / Pinecone / Milvus / Weaviate 等专用向量数据库：

向量检索是系统的核心且最主要的工作负载。
业务要求查询延迟必须稳定在极低水平（如 <10ms）。
数据集规模巨大（1 亿至数十亿甚至更多向量）。
需要执行带有多重复杂过滤条件的近似最近邻搜索。
系统需要水平扩展以应对不断增长的数据和流量。

🔄 混合架构：一种折中方案

采用 PostgreSQL 存储元数据和业务关系数据，同时使用专用向量数据库处理纯粹的向量检索。许多团队在实践中采用了这种架构，以平衡功能、性能与复杂度。

🧪 如何解读基准测试结果

不同基准测试结果差异巨大的原因在于，众多变量都会显著影响性能表现：

数据集规模与分布
目标召回率
向量维度
过滤条件的复杂度和选择性
硬件配置（CPU、内存、存储）
索引参数调优

因此，不存在一个适用于所有场景的“通用赢家”。正确的技术选择应基于对自身 特定工作负载 的深入理解，而非仅仅依赖某一份基准测试报告。

🛠 实现示例：基于 pgvector 的文档搜索系统

CREATE EXTENSION vector;

CREATE TABLE documents (
    id SERIAL PRIMARY KEY,
    title TEXT NOT NULL,
    content TEXT NOT NULL,
    category VARCHAR(50),
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    embedding vector(1536)
);

-- 创建 HNSW 索引用于向量相似度搜索
CREATE INDEX ON documents
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);

-- 为过滤字段创建传统 B-tree 索引
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 集成示例（简化）

# 假设使用 OpenAI API 生成查询的嵌入向量
response = client.embeddings.create(
    model="text-embedding-ada-002",
    input=user_query
)
query_embedding = response.data[0].embedding

# 随后将 query_embedding 用于上述 SQL 查询

🎯 结论：成熟、实用，但非万能

pgvector 已经从早期的实验性扩展，成长为众多 AI 应用在生产环境中 可靠的选择。然而，它并非旨在全面替代专用的向量数据库。

现实情况是：

对于小到中等规模的向量数据集，pgvector 表现优异。
当需要紧密融合 SQL 业务逻辑与语义搜索时，pgvector 是理想选择。
面对超大规模数据集或对延迟有极端要求的场景，pgvector 并非最佳工具。
在追求极限性能和规模扩展的场景下，专用向量数据库 依然更具优势。

当技术炒作的热潮褪去，pgvector 展现出的价值在于：它是一个非常务实、高度可用的工具，能够完美适配大量真实世界的工作负载。

📚 参考资料

pgvector GitHub 仓库 – https://github.com/pgvector/pgvector
Crunchy Data – 《使用 Postgres 和 pgvector 的性能优化建议》
Jonathan Katz – 《pgvector 性能改进分析》
Timescale – 《pgvector 与 Qdrant 基准测试对比》
Qdrant 官方文档 – 《过滤与 ANN 性能》
Microsoft Azure – 《pgvector 性能优化指南》
Google Cloud – 《使用 pgvector 进行相似性搜索》

关注“鲸栖”小程序，掌握最新AI资讯

本文由鲸栖原创发布，未经许可，请勿转载。转载请注明出处：http://www.itsolotime.com/archives/13208