Databricks 将全文搜索和向量搜索引入 Lakebase Postgres

Databricks于2026年9月28日，推出 Lakebase Search，这是一款内置于其 Lakebase Postgres 数据库的搜索引擎，通过两个扩展提供：lakebase向量用于近似最近邻搜索和 lakebase文本用于 BM25 全文搜索。这两个扩展已在 AWS 和 Azure 上普遍可用。

这些扩展使开发者能够在 Postgres 中直接运行语义、关键词和混合搜索，并与业务数据并行。Databricks 表示，传统的 OLTP 系统并未针对 AI 代理的搜索需求而构建，这类需求需要低延迟、高精度的检索，并且经常执行大规模并行搜索，而迄今为止的解决方案是将独立的搜索引擎通过 ETL 流水线连接到主数据库。该公司称，Lakebase Search 是在数百位 beta 客户的反馈基础上构建的。

基准测试结果与 Conexiom 部署

Databricks 表示，lakebase_向量在 VectorDBBench 100M 基准测试中（该基准使用 LAION 数据集）实现了比次佳系统高出两倍的吞吐量，并且其成本比使用 pgvector 的云 Postgres 供应商低四倍，且在自动扩缩容带来的额外节省之前。该公司报告称，在 97% 召回率下，P99 延迟为 71 毫秒，这意味着引擎在 97% 的情况下成功检索到真实的最近邻，并指出 pgvector 和 DiskANN 仅在单个大型实例上进行测试。

Databricks 还公布了来自 Conexiom 的客户结果，该公司在超过 1 亿行数据上运行 BM25 混合搜索，其计算资源占用仅为之前 pgvector 部署的一半。该公司称，Conexiom 的基础设施成本降低了三倍，吞吐量提升了五倍，相较于 pgvector。

“Lakebase Search 为我们提供了相较于 pgvector 全新的可扩展性水平，并在同一无服务器数据库中解锁了 BM25，”Conexiom 的 AI/ML 架构师 Jordan Voves 说。”我们使用 Lakebase 将数据大规模连接到我们的代理。”

设计背后的 Pgvector 限制

Databricks 表示，pgvector 是 Lakebase Postgres 中安装最广的扩展，并描述了在大规模使用时客户观察到的三大常见痛点。

第一点是成本随数据量而非使用量而增长。pgvector 将其 HNSW 索引保存在数据库内存中，由于 HNSW 搜索依赖随机访问的图遍历，一旦索引溢写到磁盘，查询会变成一连串随机读取，性能会下降 10 到 50 倍。一个 768 维的 float32 向量在包含图链接和 Postgres 开销后大约占用 3.3 千字节的内存，因此对 1 亿行数据的索引大约需要 330 GB 的 RAM 常驻，无论查询是否访问该索引，都必须完整分配。

第二点是索引维护。Databricks 表示，当构建过程溢写到磁盘时，pgvector 索引在标准云实例上几乎需要 50 小时才能完成构建，写入操作同样受到该瓶颈影响，因为插入向量需要随机访问遍历并修改多个图层。由于 HNSW 没有全局再平衡，恢复搜索质量必须运行完整的 REINDEX 操作，这会锁表并阻止生产写入。

第三点是单个查询无法并行化。pgvector 查询由单个 Postgres 后端进程执行，使得 HNSW 索引扫描没有任何并行性。提升召回率需要访问更多图节点，这会增加随机内存读取和距离比较，导致延迟上升并降低每秒查询数，因此要提升吞吐量只能通过增加数据库连接或只读副本来实现。

Lakebase_vector 的构建方式

Lakebase Postgres 将存储与计算分离：永久数据存放在低成本的云对象存储中，而 RAM 和本地 NVMe 则充当短暂缓存，保存活跃工作集。在此基础之上，Databricks 结合了两种技术。

层次化 IVF 聚类将向量分组为连续块存储的簇。查询在内存中对簇中心进行打分，然后仅读取少数看似有前景的块，以大规模顺序读取的方式代替大量随机跳转。采用 RaBitQ 方法的二进制量化将每个向量压缩至约每维一比特，约比 float32 小 32 倍，因此查询扫描紧凑的编码以筛选候选，并仅对该候选集进行全精度向量的重新排序。

由于该设计是无状态的，它可以实现零规模扩展，闲置时用户仅需为存储付费。Databricks 报告称，在对 1 亿个、768 维向量的数据集进行零规模扩展后的首次查询，其测得的 P90 为 1.13 秒，并表示 1 个 Lakebase Compute Unit 可服务 1 亿向量。

索引构建仅在一个小的随机样本上对聚类中心进行一次训练；随后每个向量被分配到最近的中心点，进行量化，并作为独立操作写入相应的块，从而工作会在可用的所有核心上并行展开。Databricks 表示，其 LTAP 架构将索引构建从主数据库卸载到诸如 Spark 的分布式引擎，使构建时间缩短至分钟级，并称该功能还有更多改进即将推出。由于谓词在块扫描过程中即被应用，过滤查询能够避免过度获取候选项并保持高召回率，且单个查询能够在 CPU 核心之间并行执行。

BM25 文本搜索与混合查询

Databricks 表示，标准的 Postgres tsvector 搜索缺乏全语料库的相关性上下文。lakebase_text 使用全局逆文档频率对词语进行打分，对稀有且意图明确的词赋予更高权重，对常见的填充词则权重更低。它在遍历索引时还会检查得分上限，剔除那些不可能影响前 K 名结果的整个发布块，公司称这使其比使用 GIN 索引的 tsvector 更快。

将这两个扩展结合使用即可在 Postgres 内实现原生混合搜索：单个查询既可以应用普通的 SQL 过滤谓词、连接实时运营表，又可以将语义向量得分与 BM25 关键字相关性相融合。Databricks 表示，该系统能够从单行扩展到十亿向量，并且从每秒一次的查询扩展到成千上万次，而无需手动重新配置，称其设计旨在满足 AI 代理的需求，其工作流能够在秒级内触发数千个并发检索请求。

Databricks 将 Lakebase Search 定位于希望在单一数据库中整合运营数据和搜索数据的用户，而 Databricks AI Search 则继续作为即开即用的托管检索引擎。Lakebase Search 已在 AWS 和 Azure 上正式上线；现有 Lakebase 用户可以启用这些扩展，新用户则可注册使用 Lakebase。