文章质疑pgvector在生产环境中的实际表现，指出当前多数宣传过于理想化，仅基于小规模演示而非真实生产场景。作者承认pgvector作为Postgres扩展有其价值，但强调从演示到规模化应用存在显著差距，批评相关文章缺乏对实际复杂性的讨论。

标题：关于pgvector的质疑 | Alex Jacobs

发布日期：2025年10月29日

内容概述：

理论上的完美选择

过去一年，关于pgvector作为向量数据库理想解决方案的讨论甚嚣尘上。其核心论点是：既然已在使用Postgres，而向量嵌入只是另一种数据类型，为何要增加专用向量数据库的复杂度？这一观点极具吸引力，但如同多数AI领域的夸大宣传，它刻意忽略了关键细节。

作者并非否定pgvector的价值——它确实为Postgres带来了实用的向量相似性搜索功能。但实践表明，"演示可用"与"生产可用"之间存在巨大鸿沟。

生产环境的残酷现实

现有技术文章普遍存在严重缺陷：它们大多基于小规模测试（如仅插入1万条向量），却对实际生产环境中的挑战避而不谈。这些文章会介绍安装步骤、创建向量列和简单查询，但从未揭示真实生产场景下的问题。

索引选择的困境

pgvector提供两种索引类型，各自存在显著缺陷：

1. IVFFlat索引

• 优点：内存占用低、创建速度快
• 致命缺陷：需要预设聚类数量，数据分布变化会导致搜索质量下降，必须定期重建（意味着停机或复杂维护）

2. HNSW索引

• 优点：搜索质量更优
• 致命缺陷：构建时内存消耗巨大（数百万向量可能占用10GB+内存），创建过程极其缓慢

实时搜索的幻灭

理想中的实时搜索流程（插入即查）在实际中面临两大难题：

1. IVFFlat方案：新向量会破坏原有聚类结构，必须定期重建索引
2. HNSW方案：每次插入都需更新图结构，高并发写入时会产生严重锁竞争

更严峻的是：当结合业务元数据（如文档状态、用户ID等）时，保持数据一致性的复杂度呈指数级上升。常见解决方案（如双索引、离线构建等）都伴随着性能或一致性妥协。

过滤查询的噩梦

结合业务过滤条件的向量搜索会引发更深层问题：

1. 先过滤后搜索：当过滤条件不精确时性能极差
2. 先搜索后过滤：可能遗漏优质结果（如只返回10条结果中符合过滤条件的3条）
3. 多重过滤：查询优化器难以正确处理向量搜索的特殊性

专用向量数据库已通过自适应策略、专用索引等方式解决这些问题，而pgvector用户需要自行实现全套方案。

混合搜索的额外负担

如需结合向量搜索与传统全文搜索，用户需自行解决： - 权重分配 - 分数标准化 - 结果融合算法 这些在专用数据库中本应开箱即用的功能

pgvectorscale的局限

Timescale推出的改进方案仍存在两大问题： 1. 需额外管理组件 2. 云托管服务（如RDS）尚未支持

专业建议

作者通过实践总结出关键认知： 1. 索引管理远比想象复杂 2. 查询优化需要专门知识 3. 实时索引必然伴随代价 4. 技术文章存在严重信息偏差 5. 专用数据库的存在具有合理性

最终决策不应是"是否使用pgvector"，而是"是否愿意承担在Postgres中实现向量搜索的运维复杂度"。对多数团队而言，选择专用向量数据库（如Pinecone、Weaviate等）往往是更经济高效的选择。

（注：原文中的图片链接及部分技术细节示例已省略，保留核心论证逻辑和关键数据）

以下是评论内容的总结，涵盖主要观点和论据：

支持PGVector的观点

1. 生产验证：有用户表示PGVector已在生产环境中大规模使用（如Discourse），处理了数十亿页面浏览。

   • "We do at Discourse, in thousands of databases, and it's leveraged in most of the billions of page views we serve." (评论2)
   • "I’ve seen a decent amount of production use of pgvector HNSW from our customers on GCP" (评论10)

2. 问题已解决：多个评论指出博客提到的限制（如预过滤、索引重建）已通过版本更新或第三方方案（如VectorChord）解决。

   • "This was fixed in version 0.8.0 via Iterative Scans" (评论2)
   • "We at VectorChord solved most of the pgvector issues mentioned in this blog" (评论7)

3. 简化架构：认为PGVector可减少系统复杂性，避免引入新数据库的运维负担。

   • "You should use as few services as possible, and only add something new when there’s issues." (评论5)
   • "The tradeoffs to consider are whether you want to ETL data into yet another system" (评论10)

反对或质疑PGVector的观点

1. 性能与扩展性：批评PGVector在大型数据集下的内存消耗、索引重建耗时和过滤效率问题。

   • "building an HNSW index on a few million vectors can consume 10+ GB of RAM or more... For potentially hours." (引用自博客，评论13提及)
   • "When you LIMIT 10 but only get 3 results back after filtering... you’re missing highly relevant matches." (评论19)

2. 专用数据库优势：认为专用向量数据库（如Chroma、Redis模块）在功能或性能上更优。

   • "Chroma implements SPANN and SPFresh... pre-filtering, hybrid search" (评论6)
   • "Curious if the author tried the new Redis module that brings HNSW vector search to redis." (评论11)

3. 混合搜索限制：指出PGVector在结合标量过滤时的局限性。

   • "Is there a way to do hybrid search that combines vector similarity with scalars fast using pg_vector?" (评论18)

中立/其他观点

1. 需求决定工具：强调应根据具体场景（如数据规模、更新频率）选择方案。

   • "Whether the tradeoffs are worth it really depends on your business requirements." (评论10)
   • "For these, the interface I really want is more like a file system than a database" (评论14)

2. 评测标准缺失：呼吁建立更全面的向量数据库评估体系。

   • "Is there a comprehensive leaderboard like ClickBench but for vector DBs?" (评论22)

3. 操作复杂性：部分用户认为PGVector的优化需深入技术细节，可能增加维护成本。

   • "Complexity you build and maintain yourself (pgvector workarounds)" (评论19)
   • "It seems to make sense for simple operations, but... a weird setup." (评论23)