2026年9月21日，Databricks宣布Lakebase Search正式可用（GA）。该能力把pgvector兼容的向量检索与BM25文本检索内置于Lakebase Postgres，据官方称支持10亿向量规模并带来约32倍压缩。官方在LAION-100M基准（单实例、1亿条768维向量、取top-10、单连接热缓存）上测得Recall@10为0.955、P99延迟约30ms；一个原本需要约300GB内存的1亿向量索引，如今可放入不足10GB。对后端架构与数据、尤其是向量检索数据平台团队，这是一次值得关注的更新。本文从后端架构与数据视角解读。
把向量检索真正做成 Postgres 原生能力
Lakebase Search直接在Lakebase Postgres中提供与pgvector兼容的向量检索和BM25文本检索，让开发者无需为向量单独引入一套数据库。对后端架构而言，向量检索与既有关系数据、事务语义同仓，显著降低了集成与运维复杂度，也回应了“多种检索能力收敛到单一数据平台”的趋势。
十亿级规模与约32倍压缩
官方给出的指标显示，Lakebase Search通过索引压缩把单实例索引规模扩展到1亿条（进而支撑10亿级），一个曾需约300GB内存的1亿向量索引压到不足10GB；LAION-100M基准上Recall@10约0.955、P99延迟约30ms。这类“高召回+低延迟+低内存占用”的组合，对需要大规模近似最近邻检索与结合全文搜索（混合检索）的应用具有直接参考价值。
面向Agent与检索增强的落地场景
内置在Lakebase中的向量与全文检索天然适合RAG、Agent记忆检索与文档问答等场景：BM25与向量可以同库做多路召回与重排，无需跨系统搬移数据。对正在建设统一数据平台并叠加AI检索能力的团队，这种“在数据所在处检索”的模式可以显著减少数据复制与延迟。
对后端架构与数据团队的启示
对评估向量检索方案的团队，建议把Lakebase Search放在实际数据规模与延迟预算下做基准对比，重点关注检索质量（Recall）、内存开销与和既有数据管线的融合成本；升级或迁移前注意索引构建、冷热分层（活跃集缓存于NVMe、冷尾驻留对象存储）等新模式的适配。更省内存、同仓的向量检索，是后端数据平台承载AI检索的重要方向。
小结
Databricks Lakebase Search于2026年9月21日正式可用，以lgvector兼容检索与BM25同仓、十亿级规模与约32倍压缩为核心看点，是2026年9月后端架构与数据在向量检索数据平台演进上的重要更新。