Databricks Lakebase Search、分離型検索スタックに挑む
Databricksは、マネージドPostgresサービス内に2つの検索エンジンを組み込むDatabricks Lakebase Searchを、AWSとAzureで一般提供開始した。9月28日のリリースでは、独立した検索データベースを必要とせず、ベクトル検索とBM25キーワードランキングを利用できる。これは、Postgresが運用レコードを保持し、別のシステムが検索用コピーをインデックス化するという、よく知られたAIアーキテクチャに挑むものだ。
同社によると、新しいベクトル拡張機能は、1億ベクトルをリコール率97%、P99レイテンシ71ミリ秒で検索できるという。また、自社ベンチマークにおいて次点のシステムの2倍のスループット、pgvectorを実行するクラウドPostgresの4分の1のコストを達成したとも主張している。これらの結果は注目に値するが、テストはDatabricksが実施したものであり、完全な独立検証は公開されていない。
より大きな論点は、単なる新しいベクトルインデックスではない。Databricks Lakebase Searchは、運用Postgresにエージェント規模での意味検索、キーワード検索、ハイブリッド検索を担わせようとする試みだ。このアーキテクチャが実運用ワークロードで機能すれば、一部のチームは検索サービスとそれを取り巻くデータパイプラインを削減できる可能性がある。圧力を受けるのはpgvectorのデプロイだけでなく、優れたスケールを根拠に複雑さを正当化してきた専用検索システムでもある。
Databricks Lakebase Search、検索をPostgresへ移す
今回のリリースは、検索を付随サービスから運用データベースのマネージド機能へと変える。
技術発表では、2つのPostgres拡張機能が紹介されている。lakebase_vectorは近似最近傍検索を処理する。これは、あらゆる候補レコードを比較せずに、クエリに近いベクトルを見つける方式だ。lakebase_textはBM25を提供する。これは、コレクション内の単語出現頻度、文書長、用語の希少性を考慮するランキング手法である。
両拡張機能は、AWSおよびAzure上のLakebaseプロジェクトで一般提供されている。開発者は一方の拡張機能のみを導入することも、ハイブリッド検索のために組み合わせることもできる。この組み合わせが重要なのは、ベクトル検索とキーワード検索が異なる失敗パターンに対応するためだ。
ベクトル検索は、意味を数値で表現した埋め込みを比較する。「高速なスポーツカー」というクエリに対し、まったく同じ言葉がなくても、ある自動車モデルに言及したレコードを一致させられる。一方で、識別子、名前、エラーコード、製品番号など、文字どおりの表記そのものが意味を持つ用語には、キーワード検索の方が依然として適している。
ハイブリッド検索は両手法を実行し、そのランキングを統合する。AIサポートエージェントは、意味的な類似性を使って概念的に関連するインシデントを見つけつつ、特定のエラーコードについては完全一致を維持できる。ECエージェントは、ユーザーが求めるモデル番号を取りこぼさずに、買い物客の意図を解釈できる。
これらの処理は、別途同期されたコピーではなく、トランザクションレコードの隣で実行される。開発者は、テナント、在庫状況、アクセス権、ワークフロー状態といった現在のフィールドを使って検索結果をフィルタリングできる。Databricksによれば、lakebase_vectorはインデックスブロックを走査する間にフィルタを適用し、幅広い候補集合を取得した後で、権限のない行や無関係な行を捨てる必要を減らす。
この設計は、検索システムに根強く残る問題を狙っている。レコードの最新バージョンは多くの場合アプリケーションデータベースに存在する一方、検索可能なバージョンは抽出パイプラインを経て後から到着する。短い遅延であっても、エージェントが削除済み文書、古い権限情報、あるいはすでに存在しない在庫を参照する可能性がある。
検索を運用データに近づけることで、この同期ウィンドウを縮小できる。また、エンジニアが監視、保護、修復すべきシステム数も減らせる可能性がある。この変化は、アクセス制御と文書の変更を検索結果と整合させなければならない、検索可能なナレッジベースを構築するチームにとって特に重要だ。
Lakebase Searchがすべてのデータ移動ステップをなくすわけではない。埋め込みは依然として生成する必要があり、ソースコンテンツはPostgres外部に存在する場合があり、レイクハウステーブルは提供前に同期が必要となる。違いは、アプリケーションが使い慣れたPostgresの型と演算子を通じて、生成されたインデックスをクエリできることにある。
Databricksはこの機能を、より広範なレイクハウスプラットフォームにも結び付けている。製品ドキュメントでは、Unity CatalogテーブルをLakebaseへ同期する方法を説明している。この過程で、埋め込み列はPostgresベクトルになり、ソーステキストはPostgreSQLにおけるテキスト検索向けの最適化表現であるtsvectorになる。
したがって、直近の変化は具体的だ。Lakebaseは現在、意味ベース検索と完全な用語検索のためのネイティブなマネージドインデックスを提供しており、アプリケーションはそれらを運用フィールドと並べてクエリできる。緊張が生じるのは、この統合が何を置き換えるかという点にある。
AIエージェントが分離型検索パイプラインに圧力をかける
エージェントのワークロードでは、同期エラーや遊休インフラを正当化しにくくなる。
従来の検索アーキテクチャには、通常少なくとも2つのデータストアがある。Postgresがトランザクションとアプリケーション状態を記録し、検索エンジンまたはベクトルデータベースが抽出、変換、ロードのパイプラインを通じて変換済みコピーを受け取る。
この分離は大規模環境でうまく機能することがあるが、運用上の責務も生む。チームは更新失敗を検出し、欠落したレコードを再処理し、スキーマ変更を調整し、削除の意味論を維持し、データベース権限を別のシステム内で再現しなければならない。また、アプリケーションを中断せずにインデックスを再構築する計画も必要となる。
AIエージェントは、検索が意思決定ループの一部となるため、こうした責務を増幅させる。従来の検索ページでは、ユーザーが選択肢を確認する間、不完全な結果も許容できる。エージェントはレコード取得直後に行動する可能性があり、鮮度と認可の重要性はより大きくなる。
アカウント管理エージェントはこの問題をよく示している。会議メモを意味的に検索し、正確な契約識別子に一致させ、現在のユーザー権限で結果をフィルタリングするかもしれない。この3つのシグナルが異なるシステムに存在する場合、アプリケーションはモデルが安全に応答する前にそれらを調整しなければならない。
同じ問題はコマースでも現れる。ショッピングエージェントは埋め込みによって曖昧な要求を解釈できるが、在庫状況や地域制限は急速に変化する運用列から得られる。古いコピーを検索すると、入手できない商品についてもっともらしい回答を返すおそれがある。
突発的な利用も別の圧力源となる。人間向けの企業内検索は、予測可能な勤務時間に従うことが多い。エージェントは、タスクの計画、検証、修正を行う間に、多数の並列検索呼び出しを生成できる。1件のユーザー要求が、1回ではなく複数回の検索を引き起こすこともある。
Databricksは、この不均一な需要を前提としてLakebase Searchを設計した。Lakebaseは永続ストレージとコンピュートを分離し、データをオブジェクトストレージに保持する一方、メモリとローカルNVMeをキャッシュとして使用する。検索コンピュートはアイドル時に停止し、別のクエリが到着すると再開できる。
同社は、768次元・1億ベクトルを含むインデックスでゼロスケール後、最初のクエリのP90レイテンシが1.13秒だったと報告している。また、同じコレクションを1つのLakebase Compute Unitで提供できるとしている。これらは普遍的な期待値ではなく同社測定値だが、意図された運用モデルを示している。
1秒のコールドクエリは、すべてのインタラクティブアプリケーションには適さないだろう。しかし、大規模な検索クラスターを常時稼働させずに済むなら、利用頻度の低い社内エージェントには許容できるかもしれない。レイテンシが重要な場合にはコンピュートを稼働状態に保ち、静かな環境では停止させることができる。
インデックス構築も、主たるトランザクション経路から切り離される。Databricksによれば、サンプルからセントロイドをトレーニングし、ベクトルの割り当てと量子化を分散した後、独立したインデックスブロックを書き込めるという。Sparkのような分散エンジンへの将来的なオフロードも同社の方向性の一部だが、発表では、このより広範な機能については今後の続報を待つよう述べている。
これは、大規模なインデックス構築が同じプロセッサ、メモリ、ストレージ資源を消費すると、トランザクションワークロードと競合するため重要だ。その作業を主データベースから離すことで、干渉を減らせる可能性がある。また、恒久的にプロビジョニングされたインデックスサーバーを維持するモデルから、アクティブな検索コンピュートと永続ストレージに対して支払うモデルへと、コスト構造も変化する。
圧力の対象は、すべての専用検索デプロイではない。大規模な検索チームには、専門的なアナライザー、カスタムランキングパイプライン、高度な可観測性、あるいは長年にわたって開発された機能が必要な場合が多い。Lakebaseが圧力をかけるのはむしろ、Postgres検索のスケールが難しくなったことを主な理由に、2つ目のシステムが存在する一般的なアーキテクチャだ。
この区別によって、発表内容は現実的なものになる。Databricksは、1つのデータベースがすべての検索ワークロードを実行すべきだと主張しているわけではない。より多くのAIアプリケーションが、分離を先延ばしにし、簡素化し、あるいは回避できると主張しているのだ。
Lakebaseベクトル検索、pgvectorのメモリモデルを狙う
主な競争は、大規模環境におけるストレージバック型Lakebase Searchと、メモリ負荷の高いpgvectorインデックスの間にある。
Pgvectorは、Postgresを意味検索の実用的な出発点にした。ベクトル型、距離演算子、完全検索、近似インデックスを追加し、開発者を不慣れなデータベースインターフェースへ移行させずに済む。オープンソースであり、ホスト型Postgresサービス全体で広く利用できる。
標準的な近似オプションには、HNSWとIVFFlatがある。HNSWは近接ベクトルを接続する多層グラフを構築する。速度とリコールのバランスに優れるが、グラフ構築には時間がかかり、インデックスは大量のメモリを消費する。IVFFlatはベクトルをリストに分類し、最も有望なグループを検索する。メモリと構築コストを抑えられる一方で、一般的にはクエリ性能が低くなる。
プロジェクト自身のpgvectorガイダンスは、これらのトレードオフを文書化している。HNSWインデックスは、グラフがmaintenance_work_memに収まると構築がはるかに速くなるとされている。また、検索候補を増やすとリコールは改善するが、クエリ速度を犠牲にするとも警告している。
Databricksは、HNSWグラフが1台のマシンのメモリを超えて拡大すると、これらの制約はより難しくなると主張する。リモートオブジェクトストレージからグラフノードの連鎖を取得すると、多数の小規模かつランダムな読み取りが発生し得る。常駐メモリ向けに最適化された設計は、ワーキングセットがコールド状態になると効率が低下する。
Lakebaseのベクトル検索は、階層型の転置ファイルクラスタリングを利用して、このアクセスパターンを変える。ベクトルは連続したブロックにグループ化される。クエリはまずクラスタのセントロイドをスコアリングし、その後、最も有望なクラスタに関連するブロックを読み取る。
この拡張機能は、そのレイアウトをRaBitQバイナリ量子化と組み合わせる。これは初期候補のスコアリングに向け、各ベクトルをおおよそ1次元あたり1ビットに圧縮する技術だ。Databricksは、この表現が標準的な32ビット浮動小数点ベクトルより約32倍小さいと説明している。その後、システムは完全精度ベクトルを使用して、限定された候補集合を再ランキングする。
この仕組みにより、インデックスはオブジェクトストレージとローカルキャッシュの両方により適したものになる。コールドクエリでは、数百のグラフリンクをたどるのではなく、関連する複数のブロックを読み取る。ウォームクエリでは、より小さなアクティブフットプリントをメモリに保ちながら、コンパクトなバイナリコードを走査できる。
Databricksによると、単一のlakebase_annインデックスには10億超のベクトルを保持できる。同社のドキュメントは、インデックス構築がHNSWより50〜100倍高速だとも主張している。これらの数値は同社の実装を示すものであり、あらゆるスキーマ、埋め込みモデル、フィルター分布に自動的に当てはめるべきではない。
見出しとなったベンチマークでは、LAIONデータセットから1億ベクトルを使用した。Databricksによれば、Lakebaseはテスト対象の次点システムの2倍のスループットを実現したという。同社は、P99が71ミリ秒でリコール97%を記録したと報告している。これは、測定されたクエリの99%がそのレイテンシ以内に完了し、指定の割合で真の近傍を取得したことを意味する。
このベンチマークは、pgvectorを使用する匿名のクラウドPostgresベンダーと比べてコストが4分の1になるという主張も生んだ。Databricksは、pgvectorとDiskANNが単一の大規模インスタンス上でテストされたと注記している。アーキテクチャ、構成、ハードウェア、同時実行性、料金前提によって結果が大きく変わり得るため、この留保は比較を限定する。
ベンチマークは、あるアプローチが評価に値することを示せても、購入判断を決着させるものではない。Databricksは、すべてのpgvectorワークロードが移行すべきだとは立証していない。小規模なインデックスならメモリ内に十分収まり、既存のpgvector環境は低コストで、移植性が高く、運用も容易な場合がある。
Pgvectorは、バイナリ量子化、半精度インデックス、反復スキャン、パーティショニング、設定可能な検索量もサポートしている。チューニング済みの環境を持つチームには、単純なベースライン比較チャートが示す以上の選択肢がある。このオープンソース拡張機能は多くのPostgres環境で動作する一方、Lakebase SearchはマネージドのDatabricksサービスに属する。
ただし、互換性によって移行コストは抑えられる。Databricksによると、lakebase_vectorはpgvectorのベクトル型、距離演算子、クエリ構文を使用する。アプリケーションは、HNSWまたはIVFFlatインデックスの代わりにlakebase_annインデックスを作成しながら、使い慣れたSQLを維持できる。
これは意図的な競争戦略だ。Databricksは開発者にpgvectorのプログラミングモデルを捨てるよう求めてはいない。同じインターフェースの多くを保ったまま、その下層に異なるストレージおよびインデックスエンジンを提供している。
顧客事例は実用的なシグナルを一つ与える。ConexiomはDatabricksに対し、1億行超でハイブリッドBM25検索を実行しており、従来のpgvector環境の半分のコンピュート規模で運用していると述べた。この事例は実運用ワークロードを説明している点で有用だが、独立して公開された方法論を伴わない、ベンダーが選定した顧客の発言にとどまる。
Lakebaseベクトル検索の有力な用途は、コレクションが大規模で、クエリ需要が不規則であり、運用上のフィルターが重要な場合だ。チームがインフラの移植性を優先する場合、常時稼働の需要が予測可能な場合、またはすでにpgvectorでレイテンシ目標を満たしている場合には、その利点は弱まる。
ネイティブBM25が全文検索の方程式を変える
リリースの中でより静かな部分のほうが、ベクトルベンチマークより重要かもしれない。
多くのAI検索製品は埋め込みを過大評価している。セマンティックマッチングは、ユーザーとドキュメントが異なる言葉で同じ概念を表現する場合に役立つ。一方、クエリに埋め込みモデルが弱い、あるいは未知のものとして扱う厳密な識別子が含まれる場合、その信頼性は下がる。
「CVE-2026-1234」、顧客アカウント番号、または特定のコンポーネント名を検索するエージェントを考えてみよう。類似度検索は概念的に関連するレコードを返しても、完全一致文字列の重要性を見落とす可能性がある。キーワードランキングは、リテラルな一致を維持する別の検索シグナルを提供する。
Lakebaseのlakebase_text拡張機能は、PostgreSQLのtsvector値およびテキストクエリ演算子と互換性を持つlakebase_bm25インデックスを追加する。BM25はコレクション全体の語頻度と文書長を取り入れ、希少な用語が一般的な用語より大きく寄与するのを助ける。
PostgreSQLにはすでに充実した全文検索機能がある。文書の解析、単語の正規化、ストップワードの除去、GINインデックスの構築、ts_rankまたはts_rank_cdによる結果のランキングが可能だ。公式のランキングドキュメントでは、組み込みのランク関数が語彙頻度、近接性、構造情報を使用すると説明されている。
これらの関数は、BM25と同じ方法でコレクション全体の統計を使用するわけではない。製品が単純なマッチングではなく検索エンジン型の関連性を必要とする場合、この違いは重要になる。チームはこれまで、カスタムランキングロジックを追加するか、テキストを専用エンジンへ移してきた。
Databricksによると、lakebase_textはトップK検索にBlock-Max WANDを使用する。このアルゴリズムは、現在の最高スコアと競合できる結果を生み出せない領域をスキップする。すべての一致文書を完全にスコアリングする代わりに、エンジンは要求された結果セットに入る可能性のある候補に処理を集中させる。
このアプローチはベクトル検索を補完する。サポートクエリは、正確なエラーテキストに対してlakebase_bm25で、意味的に類似したインシデント説明に対してlakebase_annで実行できる。その後、相互順位融合によって、生スコアが同じ尺度を共有すると仮定せずに、二つの順序付きリストを組み合わせられる。
ここでDatabricks Lakebase Searchは、単に高速なベクトルインデックス以上のものになる。同じデータベース内に、異なる二つの検索モデルを備えた検索スタックを提供する。運用レコード、埋め込み、テキスト表現、フィルター属性をまとめて保持できる。
この統合は、利便性と同じくらいセキュリティにも影響する。アプリケーションは、検索と並行してテナント境界や権限チェックをSQL述語として表現できる。エンジニアは依然として、すべてのインデックス経路がフィルターを正しく適用するかテストする必要があるが、別サービスで認可モデル全体を再構築する必要はない。
書き込み動作も簡素化される。新しく挿入されたレコードは、2番目のデータベースがイベントを確認するのを待たずに検索可能になり得る。更新と削除は使い慣れたトランザクション環境内にとどまるが、インデックス保守のタイミングと同期されたレイクハウスソースについては、依然として測定が必要だ。
専用エンジンには依然として重要な利点がある。Elasticsearchなどのシステムは、幅広い言語分析、カスタマイズされたスコアリング、集計、ハイライト表示、クエリツール、そして検索専用に開発された運用制御をサポートする。LakebaseのBM25サポートは、こうした差異をなくすものではない。
したがって、意味のある比較はアーキテクチャ上のものとなる。アプリケーションがセマンティック検索、厳密な語句ランキング、最新の運用フィルター、通常のSQLを必要とするなら、Lakebaseはそのワークロードのより多くを一箇所でカバーできる。検索自体が製品である場合には、専門的な機能が依然として別システムを正当化する可能性がある。
ベンチマークは本番環境の疑問を解消していない
Databricksは魅力的な仕組みを示したが、購入者には依然としてワークロード固有の根拠が必要だ。
最大の不確実性はベンチマークの独立性にある。Databricksは、公開した比較の背後にあるシステム、構成、データセット、インスタンス構成、コスト前提を選定した。同社はVectorDBBenchとLAIONの1億件データセットを特定しているが、発表内容だけでは記事中のすべての結果を再現するのに十分な詳細は提供されていない。
リコールとレイテンシも相互に作用する。近似検索は網羅的な比較を意図的に避けるため、エンジニアはクエリが調べるクラスタまたは候補の数を調整する。より高いリコールには、より多くの処理が必要になることが多い。単一の性能ポイントでは、異なる目標リコール水準にわたる全体の曲線を説明できない。
フィルタリングは、その曲線をさらに変え得る。実際のビジネスクエリでは、テナント、地域、時間、在庫状態、認可によって結果を制限する場合がある。均一に分布したベンチマークが、高度に選択的または不均一な本番フィルターを必ずしも表すわけではない。
データ形状も重要だ。LAIONの画像埋め込みは、企業文書の埋め込み、製品カタログ、ソースコード、顧客レコードとは異なる。次元数は異なり、重複が現れ、更新は不均一に届き、一部のテナントがトラフィックを支配する。それぞれの要因がキャッシュ動作とインデックス品質に影響し得る。
コールドスタート性能は慎重な解釈に値する。報告されたP90の1.13秒は、特定の1億ベクトル・768次元構成に適用される。厳しいインタラクティブ目標を持つアプリケーションでは、スケールゼロではなくアクティブなコンピュートが必要になる可能性がある。チームは最初のクエリと、それに続くバーストの両方をテストすべきだ。
運用上の制約にも注意が必要だ。ドキュメントによると、Lakebase Searchを有効にするとプロジェクト内のすべてのコンピュートリソースが再起動され、アクティブな接続が切断され、元に戻すことはできない。このため、有効化は無害な拡張機能の切り替えではなく、計画的なインフラ変更となる。
移植性も別のトレードオフだ。Lakebaseは標準的なPostgres型と使い慣れたpgvector構文を提示するが、その新しいインデックスアクセス方式はプロプライエタリなマネージド機能である。チームはアプリケーションSQLの大部分を維持できる一方、インデックス動作、スケーリング、料金についてDatabricksに依存することになる。
同じ懸念はBM25にも当てはまる。標準のtsvector列は認識可能なPostgresオブジェクトのままだが、lakebase_bm25インデックスとその実行特性はLakebase固有である。他の環境へ移行するには、インデックスの再構築とランキング品質の再テストが必要になる可能性がある。
コストに関する主張には直接的な測定が必要だ。サーバーレスの停止は不規則な利用において費用を下げ得るが、高い持続的同時実行性では別のモデルが有利になる場合がある。埋め込み生成、同期テーブル、ストレージ、データ転送、周辺のDatabricksサービスが、アーキテクチャ全体のコストに寄与する。
したがってチームは、汎用的なリーダーボードではなく代表的な質問でLakebase Searchを評価すべきだ。有用なテストコーパスには、現在のレコード、削除済みレコード、アクセス制御された文書、希少な識別子、曖昧な自然言語クエリ、そしてリコールを下げる可能性が最も高いフィルターを含める。
運用上の成果も比較すべきだ。データ鮮度、障害復旧、インデックス構築の影響、権限の一貫性、パイプライン管理に必要なスタッフ時間を測定する。外部サービスをなくすことは、生のクエリレイテンシがほとんど変わらない場合でも価値がある。
これらの疑問のいずれも、このリリースを否定するものではない。それらは、ベンダーのベンチマークの外で「最先端」が何を意味すべきかを定義する。アーキテクチャには信頼できる技術的根拠があるが、その利点が各購入者のデータ分布とワークロードにおいても維持されることを、本番環境の根拠が示さなければならない。
Lakebase SearchがGAに到達した後に注目すべきこと
Lakebase Searchが標準的なPostgres機能になるのか、それともDatabricks固有の選択肢にとどまるのかは、三つのシグナルが決める。
最初のシグナルは再現可能な性能だ。独立したテストでは、複数のリコール目標にわたって、Lakebaseをチューニング済みpgvector、DiskANNベースのサービス、専用検索エンジンと比較すべきである。インスタンス仕様、同時実行性、フィルター選択性、キャッシュ状態、インデックス構築時間、完全なコスト前提を公開すべきだ。
結果がDatabricksの主張に近ければ、ストレージバックドのクラスタ化インデックスが大規模なサーバーレスコレクションにおいて、メモリ指向のグラフより適しているという見方が強まる。大きな差があれば、統合に運用上の利点が残るとしても、性能面の主張は弱まる。
二つ目のシグナルは、二つのシステムからなるアーキテクチャを置き換えるチームでの採用だ。Conexiomは初期の一例を示しているが、市場には本番規模、更新頻度、クエリ量、権限モデルを説明するより多くの事例が必要だ。最も説得力のある事例は、単なる成功したデモではなく、廃止された検索クラスタやETLパイプラインを記録するだろう。
採用状況は、使い慣れたPostgres構文が移行時の摩擦を減らすかどうかも明らかにする。チームがデータモデルとクエリを維持したままインデックス定義を変更できるなら、Lakebase Searchは既存アプリケーションへ入る実用的な経路を持つ。移行に大規模なランキング変更が必要なら、互換性の主張は説得力を失う。
3つ目のシグナルは競合の対応だ。Pgvectorは量子化、フィルタリング、反復スキャンの選択肢を引き続き拡充している。マネージドPostgresベンダーはストレージアーキテクチャを改善したり、独自の検索拡張機能を導入したりできる。専業検索プロバイダーは、成熟したランキング制御、デプロイの柔軟性、ハイブリッド検索機能を強調できる。
Databricksは、2025年のローンチ発表で、LakebaseをAIアプリケーション向けのマネージドPostgresとして位置付け始めた。今回のリリースは、その位置付けをより具体的なものにしている。重要な検索クエリのたびにシステム外へ出なければならないなら、トランザクション機能だけでデータベースがエージェント対応になるわけではない。
当面の要点は、より限定的で実用的だ。Databricks Lakebase Searchは、運用レコード、ベクトル類似性、BM25ランキング、SQLフィルタリングを開発者に単一のマネージド環境で提供する。クラスタ化・量子化されたベクトルインデックスは、大規模なpgvectorデプロイを制約するメモリモデルに直接対応している。
次の判断はエンジニアリングチームに委ねられる。代表的な検索テストを構築し、コールドトラフィックとウォームトラフィックを含め、実際の権限フィルターを適用したうえで、運用負荷全体を比較すべきだ。Lakebaseが関連性を維持しながら同期インフラを不要にできるなら、アーキテクチャの簡素化は、どの単一ベンチマークの数値よりも重要になる。
