LanceDB 加载 10 万个 OpenAI 嵌入的速度比 pgvector 快 22 倍，而 pgvector 在处理来自八个并发客户端的相同工作负载时，速度快了 1.8 倍。在单线程延迟和存储效率方面的差距也向 LanceDB 倾斜，为开发者提供了一种数据驱动的方式来选择向量数据库。

为什么现在进行基准测试很重要

向量搜索已从研究实验室转向生产服务，例如推荐引擎和检索增强生成 (RAG)。大多数团队已经在运行 PostgreSQL，因此 pgvector 扩展可以在不引入新基础设施的情况下提供相似性搜索。然而，像 LanceDB 这样的专用存储库声称具有更低的延迟和更廉价的存储。团队必须在“添加到现有架构”和“运行专用引擎”之间做出选择，随着数据集的增长和请求率的上升，这一决策将影响成本和性能。

测试是如何设置的

两个系统都对由 OpenAI 嵌入模型生成的 10 万个向量进行了索引，每个向量为 1536 维。我们测量了摄取速度、磁盘占用、单线程查询延迟以及八个并发客户端下的吞吐量。

正面对决结果

  • 摄取速度 – LanceDB 展现出 22 倍的优势。
  • 磁盘占用 – LanceDB 存储向量所占用的空间大约仅为 pgvector 的三分之一。
  • 单线程延迟 – LanceDB 上的查询速度快了约两倍。
  • 并发扩展性 – 在八个并行客户端的情况下，pgvector 的吞吐量比 LanceDB 高出 1.8 倍。

差异的架构根源

LanceDB 是一个嵌入式库，运行在托管应用程序的 Python 进程内部。所有操作都在进程内完成，因此数据永远不会跨越网络边界，且索引更新的开销极小。这种设计在单任务工作负载中表现出色，但当多个 Python 线程争夺全局解释器锁 (GIL) 时会遇到瓶颈，因为 GIL 会阻止 Python 字节码的真正并行执行。

pgvector 在服务器端扩展了 PostgreSQL。每个客户端连接都会启动一个单独的服务器进程，从而完全绕过了 GIL。PostgreSQL 规划器决定如何执行相似性搜索，并且服务器可以启动许多进程来处理并发请求。这种隔离性解释了其在负载下更好的扩展性。

过滤与查询规划的特性

现实世界的 RAG 流水线通常将向量相似性与传统过滤器结合使用（例如 WHERE user_id = 42）。LanceDB 应用预过滤，其行为在多次运行中是可预测的。pgvector 依赖 PostgreSQL 的查询规划器，该规划器可能会根据统计信息选择快速的索引扫描或退回到较慢的精确扫描。在批量加载 pgvector 表后运行 ANALYZE 可以刷新这些统计信息；如果不运行，召回率可能会降至接近零，从而实际上破坏了搜索功能。

何时选择哪种方案

如果符合以下情况，请选择 pgvector

  • 你的技术栈中已经包含了 PostgreSQL，并且你想避免添加另一个服务。
  • 你预期会有大量并发用户或 API 调用。
  • ACID 保证和熟悉的 DBA 工具对你很重要。

如果符合以下情况，请选择 LanceDB

  • 你的工作流是机器学习 (ML) 流水线，需要频繁摄取新的嵌入。
  • 你需要最快的写入路径，以及针对单请求智能体（例如聊天机器人）的低延迟。
  • 磁盘成本是一个考虑因素，且你可以容忍单线程性能的上限。

总结： 如果原始摄取速度、最小存储占用和单请求延迟最为重要，那么 LanceDB 胜出。如果你必须同时为大量用户提供服务，并且依赖现有的 PostgreSQL 部署，那么 pgvector 的并发优势使其成为更稳妥的选择。请利用本次基准测试的数据，根据产品最关键的指标来匹配合适的存储方案。