Databricks が Lakebase Postgres にフルテキスト検索とベクトル検索を導入

Databricks は 2026年9月28日、Lakebase Search を導入した、同社の Lakebase Postgres データベース向けに組み込み型検索エンジンで、2 つの拡張機能を通じて提供されます：lakebasevector（近似最近傍検索用）と lakebasetext（BM25 フルテキスト検索用）。両方の拡張機能は AWS と Azure で一般提供されています。

これらの拡張機能により、開発者は Postgres 内で運用データと並行してセマンティック検索、キーワード検索、ハイブリッド検索を直接実行できます。Databricks は、従来の OLTP システムは低レイテンシかつ高精度の検索を必要とし、大規模な並列検索を頻繁に実行する AI エージェントの検索要求に対応していないと述べ、これまでの解決策はスタンドアロンの検索エンジンを ETL パイプラインでプライマリデータベースに接続することだったと指摘しました。同社は、数百人のベータ顧客からのフィードバックと共に Lakebase Search を構築したと述べています。

ベンチマーク結果と Conexiom の導入

Databricks は、VectorDBBench 100M ベンチマーク（LAION データセット使用）において、lakebase_ベクトル が次点システムの 2 倍のスループットを提供し、pgvector を使用するクラウド Postgres ベンダーよりも 4 倍安価であると述べました（オートスケーリングによる追加のコスト削減を除く）。同社は、リコール率 97% で P99 レイテンシが 71 ミリ秒であると報告しており、エンジンが真の最近傍を 97% の確率で正しく取得したことを意味します。また、pgvector と DiskANN は単一の大規模インスタンスでのみテストされたことも指摘しています。

Databricks は、Conexiom の顧客事例も報告しました。同社は 1 億行以上にわたる BM25 ハイブリッド検索を、従来の pgvector 設定の半分の計算リソースで実行しています。Conexiom のインフラコストは 3 倍に削減され、スループットは pgvector に比べて 5 倍に向上したと同社は述べています。

「Lakebase Search は pgvector に比べて全く新しいスケーラビリティを提供し、同じサーバーレスデータベースで BM25 を活用できるようにします」と Conexiom の AI/ML アーキテクト、Jordan Voves 氏は述べました。「私たちは Lakebase を使用して、データをエージェントに大規模に接続しています。」

設計の背後にある Pgvector の制限

Databricks は、pgvector が Lakebase Postgres で最もインストールされている拡張機能であり、スケールで運用する顧客から観測された 3 つの繰り返し発生する課題を説明しました。

最初の課題は、使用量ではなくデータ量に比例してコストが増大することです。pgvector は HNSW インデックスをデータベースメモリに保持しますが、HNSW 検索はランダムアクセスのグラフトラバーサルに依存するため、インデックスがディスクにスピルし、クエリがランダムリードの連鎖になると、パフォーマンスは 10 倍から 50 倍低下します。768 次元の float32 ベクトルは、グラフリンクと Postgres のオーバーヘッドを含めると約 3.3 キロバイトのメモリを使用します。そのため、1 億行のインデックスは約 330 ギガバイトの RAM を常駐させる必要があり、クエリがアクセスしようとしなくてもフルでプロビジョニングされます。

2 番目の課題はインデックスの保守です。構築時にディスクにスピルした場合、標準的なクラウドインスタンス上で pgvector インデックスの構築に約 50 時間かかると Databricks は述べており、ベクトルの挿入はランダムアクセスのトラバーサルと複数のグラフ層の変更を必要とするため、書き込みも同様のボトルネックに直面します。HNSW には全体的な再バランスがないため、検索品質を回復するにはフル REINDEX を実行する必要があり、この操作はテーブルをロックし、プロダクションの書き込みを停止させます。

3 番目の課題は、単一クエリが並列化できないことです。pgvector のクエリは 1 つの Postgres バックエンドプロセスで実行されるため、HNSW インデックススキャンに並列化がありません。リコール率を上げるにはより多くのグラフノードを訪問する必要があり、これによりランダムメモリリードと距離比較が増加し、レイテンシが上昇し、1 秒あたりのクエリ数が減少します。そのため、スループットを拡大するにはデータベース接続数やリードレプリカを増やす必要があります。

Lakebase_vector の構築方法

Lakebase Postgres はストレージとコンピュートを分離しています。永続データは低コストのクラウドオブジェクトストレージに格納され、RAM とローカル NVMe はアクティブな作業セットを保持する短命キャッシュとして機能します。この基盤の上に、Databricks は 2 つの手法を組み合わせました。

階層的 IVF クラスタリングはベクトルを連続ブロックとして格納されたクラスタにグループ化します。クエリはメモリ内でクラスタ中心をスコアリングし、次に有望と思われる少数のブロックだけを大規模なシーケンシャルリードとして読み取ります。RaBitQ 手法を用いたバイナリ量子化により、各ベクトルは次元あたり約 1 ビットに圧縮され、float32 の約 32 分の 1 のサイズになります。そのため、クエリはコンパクトコードを走査して候補を絞り込み、絞り込んだリストをフル精度ベクトルに対して再ランク付けします。

設計がステートレスであるため、ゼロスケールが可能で、アイドル時はストレージ料金のみが課金されます。Databricks は、1 億ベクトル、768 次元のデータセットでスケール・トゥ・ゼロ後の最初のクエリに対し、測定された P90 が 1.13 秒であると報告し、1 つの Lakebase Compute Unit で 1 億ベクトルを処理できると述べました。

インデックス構築は、小さなランダムサンプルに対してクラスタのセントロイドを一度だけ学習します。その後、各ベクトルは最も近いセントロイドに割り当てられ、量子化され、独立した操作として適切なブロックに書き込まれるため、利用可能なコア数に応じて処理が分散されます。Databricksは、同社のLTAPアーキテクチャがインデックス構築をプライマリデータベースからSparkなどの分散エンジンへオフロードし、構築時間を数分に短縮すると述べ、さらに機能強化が予定されていると付け加えました。ブロックスキャン時に述語が適用されるため、フィルタクエリは候補の過剰取得を回避し、リコールを高く保ち、単一クエリはCPUコア間で並列化されます。

BM25 テキスト検索とハイブリッドクエリ

Databricksは、標準的なPostgresのtsvector検索はコーパス全体の関連性コンテキストが欠如していると指摘しました。lakebase_textは、グローバルな逆文書頻度（IDF）を用いて用語をスコア付けし、希少で意図の高い用語により大きな重みを、一般的なフィラー語には低い重みを与えます。また、インデックスを走査しながらスコアの上限をチェックし、上位K結果に影響し得ない投稿ブロック全体を破棄します。同社は、これによりGINインデックスを使用したtsvectorよりも高速になると述べています。

この2つの拡張機能を組み合わせることで、Postgres内部でネイティブなハイブリッド検索が可能になります。単一のクエリで通常のSQLフィルタ述語を適用し、リアルタイムの運用テーブルと結合し、セマンティックベクトルのスコアリングとBM25キーワード関連性を統合できます。Databricksは、システムは1行から10億ベクトル、1秒あたり1クエリから数千クエリへと手動での再プロビジョニングなしにスケールすると述べ、この設計は数秒以内に数千件の同時検索リクエストをトリガーできるAIエージェント向けに意図されていると説明しています。

Databricksは、運用データと検索データを単一のデータベースに統合したいユーザー向けにLakebase Searchを位置付けており、Databricks AI Searchは即座に利用可能なマネージド検索エンジンとして提供し続けています。Lakebase SearchはAWSおよびAzureで一般提供されており、既存のLakebaseユーザーは拡張機能を有効化でき、新規ユーザーはLakebaseにサインアップできます。