Lakebase Search: State-of-the-art full text and vector search for Postgres

Lakebase Search：面向 Postgres 的前沿全文与向量搜索 | Databricks 博客

跳至主要内容

Lakebase

2026 年 9 月 28 日

Lakebase Search：面向 Postgres 的前沿全文与向量搜索

Postgres 中快速、可扩展且无服务器的搜索功能现已正式发布

作者：周孙、周金静、杨 keming、崔 Usamoi、Pranav Aurora 和陈俊宇

摘要

• Lakebase Postgres 现在内置了搜索引擎（AWS/Azure 上已正式发布）。通过两个扩展模块 lakebase_vector（ANN 搜索）和 lakebase_text（BM25），您可以在 Postgres 中直接对操作数据执行语义搜索、关键字搜索和混合搜索，无需单独的搜索系统 + ETL 管道。

• 在大规模数据场景下，其性能优于 pgvector 和专用搜索引擎。在 1 亿向量基准测试中，Lakebase 的吞吐量是次优系统的 2 倍，成本仅为使用 pgvector 的云 Postgres 的 1/4，且在 71 毫秒 P99 延迟下达到 97% 的召回率。通过将存储与计算分离，并采用分层 IVF 聚类 + 二进制量化（RaBitQ）技术，Lakebase 仅访问所需数据即可实现这一性能。

• 架构为无服务器设计，可扩展至零。您按查询使用量付费，而非数据量。索引构建从主数据库卸载，冷启动仅需约 1 秒，单个计算单元即可服务 1 亿向量，专为 AI 代理的突发检索模式而设计。

传统 OLTP 系统并未为 AI 代理的搜索需求而构建。它们需要在所有数据上实现低延迟、高精度的检索，且经常执行大规模并行搜索。此前，解决这一问题需要通过 ETL 管道将独立搜索引擎与主数据库进行“胶带式”连接。

但如果您的 OLTP 数据库能够高效运行搜索任务会怎样？

今天，我们通过两个扩展模块为 Lakebase Postgres 带来快速且可扩展的搜索引擎：lakebase_vector（可扩展近似邻居搜索）和 lakebase_text（BM25 全文搜索）。这两个扩展模块现已在 AWS 和 Azure 上正式发布。

借助 lakebase_vector，Postgres 现在处于向量搜索的前沿。其效率和可扩展性优于专用搜索引擎。在 VectorDBBench 1 亿基准测试中，其吞吐量是次优系统的 2 倍，成本仅为使用 pgvector 的云 Postgres 供应商的 1/4，这还不包括自动扩展带来的额外节省。

VectorDBBench LAION 1 亿数据集。注意：对于 pgvector 和 DiskANN，我们仅在单个大型实例上测试了性能。

它在保持性能的同时不牺牲准确性。在我们的测试中，lakebase_vector 在 97% 召回率下实现了 71 毫秒的 P99 延迟（成功检索真实最近邻居的 97% 情况）。

1 亿 LAION 数据集的延迟和召回率

Lakebase Postgres 现在具备前沿的搜索能力，我们已看到客户如 Conexiom 在超过 1 亿行数据上使用 BM25 进行混合搜索，计算资源消耗仅为之前 pgvector 架构的一半。他们现在拥有一个完全无服务器且可根据需求扩展的数据库，可处理所有 OLTP 和搜索工作负载。

Lakebase Search 使我们相比 pgvector 实现了全新的可扩展性，并在同一个无服务器数据库中启用了 BM25。我们使用 Lakebase 在大规模场景下将数据连接到我们的代理。——Conexiom AI/ML 架构师 Jordan Voves

为什么 pgvector 在大规模场景下会遇到瓶颈

对于大多数PostgreSQL用户来说，搜索通常从pgvector开始。它允许通过HNSW和IVFFlat等索引算法在PostgreSQL中原生执行向量相似性搜索，避免了使用独立向量存储的复杂性。事实上，pgvector是Lakebase PostgreSQL中安装最广泛的扩展。我们在大规模运行pgvector的客户中发现了三个常见的痛点。

首先，成本随数据量增长，而非使用量

pgvector将索引存储在数据库内存中以实现快速访问。由于HNSW搜索依赖于随机访问图遍历，只有当所有数据完美适配于RAM时，查询才能在毫秒级完成。一旦索引溢出到磁盘，查询就会变成随机读取链，性能会下降10到50倍。

HNSW在内存使用上成本较低，但溢出到磁盘会变成一系列往返操作。

一个768维的float32向量在考虑图链接和PostgreSQL开销后，大约需要3.3KB内存。在1亿行数据时，需要约330GB内存才能保持索引驻留以实现毫秒级查询。没有所谓"工作集"的概念。无论是否查询全部数据，都需要为整个索引分配资源。

其次，索引维护成本高昂且会阻塞数据库

pgvector索引受内存限制，因为HNSW图依赖于连续的随机访问。当构建过程溢出到磁盘时，数百万次的随机I/O操作会严重影响性能——在标准云实例上构建pgvector索引可能需要近50小时。

数据摄入同样面临瓶颈。插入新向量速度慢且成本高，因为每次写入都迫使pgvector通过随机访问查找来修改图的多个层级。

HNSW依赖于连续的随机访问图导航，同时需要修改图的每一层。因此HNSW索引

持续维护会加剧问题。由于HNSW缺乏全局再平衡机制，恢复搜索质量需要执行完整的REINDEX操作，这会锁定表并阻塞生产写入。

第三，你必须在搜索质量与性能之间做出取舍

每个pgvector查询都在单个PostgreSQL后端进程中运行，这意味着HNSW索引扫描从不会并行化。

要获得更高的召回率，引擎必须访问更多图节点，触发更多随机内存读取和距离比较。这会增加延迟并降低QPS。由于单次搜索无法跨核心并行化，你唯一提高吞吐量的选择就是增加更多连接或读取副本。

lakebase_vector为PostgreSQL带来可扩展的向量搜索

pgvector的主要瓶颈在于整个索引必须适配单台机器的RAM才能实现快速访问。如果不需要呢？

Lakebase PostgreSQL为我们提供了很好的起点，因为它将存储与计算分离。持久化数据存储在廉价的云对象存储中，而RAM和本地NVMe则作为临时缓存位于其前面，用于快速读取数据的工作集。在这种架构下，HNSW缓存意味着一系列随机对象存储读取。

我们需要一种在内存缓存和对象存储冷数据时都快速的索引。我们利用了两个理念：

• 分层IVF聚类。向量被分组为存储为连续块的聚类。查询在内存中对聚类中心进行评分，然后只读取少数有希望的块——将数百次随机跳转转化为少量大容量顺序读取。

• 二进制量化 (RaBitQ)。每个向量被压缩为每个维度约1位，体积仅为float32的约1/32。查询通过扫描紧凑的编码来筛选候选对象，然后对有限的候选列表进行全精度向量的重新排序。

当数据被缓存时，搜索操作通过量化向量在极小的存储 footprint 上执行。在冷启动时，查询仅获取所需的数据块，无需遍历整个索引。Lakebase_vector 提供：

仅按实际使用付费，可扩展至零

将存储与计算解耦使 lakebase_vector 完全无状态：节点按需缓存热点数据，在空闲时暂停至零状态，下次查询时自动恢复。

• 静态存储时仅按存储付费，为在 Lakebase 中保持向量索引提供低基准成本。

• 冷启动成本低廉，因为只有量化编码和查询涉及的具体数据块会被加载。我们测得从零扩展后的首次查询 P90 延迟仅为 1.13 秒（1亿 × 768维）。

• 即使在单个 Lakebase 计算单元（CU）上也可以服务 1亿个向量。仅需在计算节点缓存活跃数据集，这种定价模式真正贴合实际使用和查询行为。

快速的离线索引构建

lakebase_vector 以更并行化的方式构建索引。我们首先在小规模随机样本上训练一次聚类中心，这是唯一需要遍历整个数据集的步骤。之后每个向量独立分配到最近的聚类中心，进行量化后写入对应聚类的数据块。该过程可扩展至任意数量的 CPU 核心，计算资源越多性能越强。

我们更进一步将索引构建完全从主数据库卸载。通过开放格式存储数据，LTAP 架构可将索引和维护工作委托给 Spark 等分布式引擎，借助并行计算将构建时间缩短至分钟级。敬请期待。

快速且精准的搜索

lakebase_vector 通过紧凑的 1-bit 编码以低成本扩展候选集搜索，仅对精简的候选列表进行全精度重新排序。由于索引块相互独立，单个查询可跨 CPU 核心并行执行，同时实现高召回率和低延迟。

过滤操作直接在 lakebase_vector 扫描聚类块时进行。内联应用过滤条件可避免过度获取候选对象，保持过滤查询的高召回率。

lakebase_text：Postgres 原生 BM25 搜索

标准 Postgres 文本搜索（tsvector）缺乏全局语料相关性上下文。lakebase_text 通过使用全局逆文档频率（IDF）对术语进行评分，为 Postgres 带来原生 BM25 搜索：对罕见的高意图术语赋予高权重，同时对常见填充词进行惩罚。

它比传统的 tsvector + GIN 索引更快。通过在遍历过程中评估得分上限，引擎可跳过无法达到前K结果的整个倒排块。

将 lakebase_text 与 lakebase_vector 结合，可在 Postgres 中实现原生混合搜索。单个查询中可融合语义向量搜索与 BM25 关键词相关性，应用标准 SQL 过滤条件，并直接与实时操作表进行关联。

Lakebase Postgres 专为智能体时代而生

智能体已将传统搜索引擎推至极限。它们使向量搜索成为数据栈的核心需求，并引入了极端突发性，单个工作流可在数秒内触发数千个并发检索请求。

我们专门为这种新现实设计了 Lakebase Search。现在 Lakebase Postgres 可以通过无服务器架构处理所有操作和搜索工作负载，该架构能够无缝扩展，从 1 行到 10 亿个向量，从 1 QPS 到数千 QPS，无需手动重新配置或管理基础设施。

我们在数百位测试客户的反馈基础上构建了 Lakebase Search，结果证明了其价值：

• 数据库支出降低 3 倍：Conexiom 在基础设施成本降低 3 倍的同时，相比 pgvector 实现了 5 倍更高的吞吐量。
• 代理只需一次 SQL 调用：开发者用一个 SQL 调用替代复杂的多系统检索流水线，实现原生混合搜索，遵循标准数据库规则。
• 操作和搜索统一：团队将实时操作表和专用搜索集群整合到一个按需付费的后端。

Lakebase Search 今天已在 AWS 和 Azure 上正式发布。如果您已经在 Lakebase 上构建应用或代理，只需启用扩展功能即可。如果您尚未尝试过 Lakebase，立即开始体验。

▎ 📝 注意：Databricks AI Search 是开箱即用的高质量检索管理搜索引擎——当您希望获得无需手动调优的出色结果时，这可能是更合适的选择。而当您希望将所有操作和搜索数据统一到一个数据库时，Lakebase Search 是更优选择。

订阅获取最新文章

订阅我们的博客，最新文章将直接发送到您的邮箱。

注册

查看所有博客

slice-start id="_gatsby-scripts-1"

slice-end id="_gatsby-scripts-1"