Databricks、Lakebase Postgresのコンピュートキャッシュを改善、真の試金石はオートスケーリング

Databricksは、新たな構成によりLakebase Postgresのコンピュートキャッシュ性能を改善しており、本番環境での測定では最大2倍のスループットを記録した。この変更は、80コンピュートユニット以上の固定サイズDatabricksコンピュートですでに有効になっている。しかし、より困難な課題は未解決のままだ。Postgresの稼働中に拡張・縮小するコンピュートへ、同じメモリ戦略を適用することである。

この更新は、頻繁に要求されるデータベースページがどこで処理時間を過ごすかを変える。大規模な固定サイズコンピュートでは、利用可能なメモリの最大75%をPostgres共有バッファに割り当てる。これらのバッファは、データベースエンジンで最も高速なインメモリキャッシュだ。Databricksはさらに、OS内部でのアドレス変換処理を減らすため、そのメモリを2 MBの巨大ページで支える。

この組み合わせは、分離型データベースにおける中心的な緊張関係を対象としている。永続ストレージをコンピュートから分離すると、高速な再起動、独立したスケーリング、低コストのオブジェクトストレージが可能になる。しかしその一方で、実行中のクエリと必要なデータとの距離は広がる。Amazon Aurora、AlloyDB、その他のクラウドデータベースもこの問題の変種に直面しているが、DatabricksはLakebaseの基盤となるNeonアーキテクチャに対してこの修正を適用している。

Lakebase Postgresのコンピュートキャッシュ改善は固定コンピュートから始まる

DatabricksはLakebaseキャッシュの最もホットな部分をローカルディスクからPostgresメモリへ移したが、対象は十分に大きな固定サイズマシンに限られる。

この変更は2026年9月9日に公表された。同社のコンピュートキャッシュ更新によると、80コンピュートユニット以上の固定サイズLakebaseコンピュートで有効になっている。Neonでの同等の展開は、18コンピュートユニット以上の固定コンピュートを対象とする。

Lakebaseは分離型ストレージを採用しており、Postgresコンピュートと永続データストレージは別レイヤーとして動作する。コンピュートノードはデータベースエンジンを実行するが、データの権威あるコピーを保持しない。この設計により、運用担当者はデータベース全体を移動せずにコンピュートを置き換え、再起動、またはリサイズできる。

読み取りは階層を経由する。PostgresはまずDRAM内の共有バッファを確認する。ページがなければ、従来の構成ではコンピュートノードのNVMeドライブに保存されたローカルファイルキャッシュを確認する。さらにミスした場合、リクエストは分散ストレージレイヤーに送られ、pageserverがデータベースページを再構築して返す。

このローカルファイルキャッシュは、初期段階の重要な問題を解決した。標準的なPostgresインストールでは通常、共有バッファとOSのページキャッシュの両方の恩恵を受ける。Lakebaseはリモートページ読み取りを従来型のローカルファイルシステム経由で処理しないため、通常の第2層に依存できない。

そのためDatabricksとNeonは、ローカルファイルキャッシュを弾力的な代替手段として構築した。これは静的なPostgresバッファ割り当てを超える容量を使用でき、サーバーレスコンピュートとともに調整できた。この構成は、稼働中のPostgresに共有バッファのリサイズを求めることなく、オートスケーリングを支えた。

ただし、従来の構成では共有バッファはおよそ1 GBに制限されていた。DRAMの75%に達し得る残りのコンピュートキャッシュ容量の大半は、ローカルファイルキャッシュに割り当てられていた。大規模マシンでは、この配分によって、本来キャッシュ可能な読み取りの多くがメモリではなくNVMeを経由していた。

新たな固定コンピュート構成では、この経路からローカルファイルキャッシュを外す。DRAMの75%を共有バッファに割り当て、はるかに大きなワーキングセットをPostgres内に保持する。発表によると、管理者がshow shared_buffersを実行した場合、80ユニットのDatabricksエンドポイントでは120 GBが表示されるはずだ。

DRAMアクセスは、ローカルキャッシュで必要となるディスク入出力を回避する。また、Postgresはキャッシュされたページとその利用状況を直接把握できる。OSキャッシュや別個のディスクレイヤーは、どのページを追い出すべきかを判断する際、データベース状態について得られる情報が少ない。

これが、Lakebase Postgresのコンピュートキャッシュを改善することの直接的な意味である。これは新しいインデックス、クエリプランナー、ストレージ形式ではない。Databricksは、既存のPostgres実行エンジンを取り巻くメモリ割り当てと仮想メモリの仕組みを変更した。

対象範囲は重要だ。固定サイズのデプロイメントでは、メモリ上限が既知のままなので、起動時に共有バッファを割り当てられる。オートスケーリングエンドポイントでは同じ前提を置けない。利用可能なメモリはワークロード需要に応じて変化する一方、標準的なPostgres設定は起動後も静的なままである。

そのため、最初のリリースは意義がある一方で完成形ではない。Databricksは、メモリをより直接的に利用することで、大規模Lakebaseエンドポイントを改善できることを示した。しかし、分離型Postgresを魅力的にするサーバーレス運用モデル全体に、同じ設計をまだ提供してはいない。

Lakebaseのキャッシュ性能が優先課題となった理由

ストレージ分離は運用の柔軟性をもたらすが、キャッシュミスのたびに、その柔軟性の背後に隠れたレイテンシとCPUコストが露わになる。

従来のPostgresは通常、クエリエンジン、先行書き込みログ、データベースファイルを1台のマシン、または密接に接続されたストレージ上にまとめる。OSは最近アクセスされたファイルページをページキャッシュに保持できる。Postgresも選択したページを共有バッファに保持する。

この構成では、メモリ内にデータが重複する場合がある。Databricksは、4 GBのRAMを持ち、共有バッファに1 GBを割り当てたマシンの例を示す。ファイルシステム経由で1 GBを読み取ると、OSキャッシュにも別のコピーが残り、1 GBのデータベースページをキャッシュするために2 GBを消費し得る。

Lakebaseは経路を変える。同社のストレージアーキテクチャは、システムをステートレスなPostgresコンピュートと永続ストレージサービスに分割する。safekeeperは先行書き込みログのレコードを複製し、pageserverはページバージョンを再構築してオブジェクトストレージに永続化する。

このアーキテクチャにより、コンピュートは保存済みデータとは独立してスケールできる。データベース全体をコピーすることなく、スケール・トゥ・ゼロ、高速ブランチ、読み取りレプリカ、フェイルオーバーなどの機能を支える。これらの利点は、永続状態をコンピュートノードの外部に維持することに依存する。

それでも、ステートレスなコンピュートはクエリ処理中に状態を手元に置く必要がある。アプリケーションは、インデックス、テーブルページ、カタログレコード、その他の構造に繰り返しアクセスする。これらのページがDRAMに残っていれば、読み取りは階層中で最も低レイテンシの部分を通じて完了する。

共有バッファでのミスは、より長い経路をたどる。ローカルNVMeキャッシュはリモートストレージより高速だが、それでもディスクアクセスと追加のソフトウェア処理を必要とする。そこでのミスはpageserverに到達し、ネットワークトラフィックとページ再構築作業を追加する可能性がある。

結果として、この負荷はレイテンシに敏感なアプリケーション向けに大規模Lakebaseインスタンスを利用するチームに及ぶ。こうした顧客は十分なメモリをプロビジョニングしているが、従来の1 GB共有バッファ上限により、Postgresはその大半を最速のキャッシュ経路で利用できなかった。

この不整合は、ワーキングセットが大きくなるほど目立つ。ワーキングセットとは、ある期間にアプリケーションが頻繁にアクセスするページの集合である。これが小さなメモリキャッシュを超えると、マシンに十分なDRAMがあっても、リクエストはより遅いレイヤーへ流出する。

Lakebaseは分析ジョブだけでなく、運用ワークロードにも対応するようになっているため、Databricksにはより良い答えが必要だった。ユーザー向けアプリケーションは、レイテンシ分布の末尾近くにある遅いリクエストを示すテールレイテンシを重視する。平均値が許容範囲にとどまっていても、p99リクエストが目に見える待ち時間を生むことがある。

AIアプリケーションも、運用データベースに不均一な負荷をかける。エージェントは、検索、書き込み、チェックポイント、並行したツール呼び出しの急増を引き起こす可能性がある。トラフィックが安定したリクエストストリームではなく集中して到来する場合、予測可能なキャッシュ動作はより重要になる。

これは、すべてのワークロードが同程度に恩恵を受けることを意味しない。データセットがすでに従来の共有バッファ割り当てに収まっている場合、改善の余地は小さい。ページ再利用が少ないスキャン中心のワークロードは、バッファサイズにかかわらず、引き続き下位のキャッシュ階層に到達する可能性がある。

最も有力な候補は、以前の1 GB上限を超える再利用可能なワーキングセットを持つ大規模エンドポイントだ。既存のメモリで、より多くのホットページをPostgres内に直接保持できる。Databricksが普遍的な2倍化を約束するのではなく、本番環境の例を提示したのはこのためである。

したがって、Lakebaseのキャッシュ性能はマシンサイズと同じくらいワークロード形状に依存する。新しい構成は、アーキテクチャ上のボトルネックを1つ取り除く。ただし、キャッシュ局所性、クエリ設計、インデックス、メモリ競合を支配する基本原則を覆すものではない。

巨大ページがより大きなバッファプールを実用的にする

Postgresへのメモリ割り当てを増やすだけでは、Lakebaseがデータベースプロセス間でそのメモリをマッピングするコストも削減しない限り、それ自体がオーバーヘッドを生む。

Postgresはプロセスベースのアーキテクチャを採用している。通常、アクティブな接続ごとにバックエンドプロセスが割り当てられ、各バックエンドは共有バッファ領域を仮想アドレス空間にマッピングする。OSは、これらの仮想アドレスを物理メモリ上の位置に変換するページテーブルエントリを維持する。

標準的なLinuxメモリページは一般に4 KBである。このページサイズでは、1 GBの共有バッファには、領域をマッピングするプロセスごとに262,144個のページテーブルエントリが必要になる。Databricksの計算によると、512バックエンドで32 GBの共有バッファを使用する場合、約43億個のエントリが必要になり得る。

同社は、32 GBのキャッシュをマッピングするだけのページテーブルが約32 GBを消費すると見積もっている。これは、より大きなバッファ割り当てがオーバーヘッドを別の場所へ移す可能性を示す極端な例だ。メモリ管理が過剰なRAMとCPU時間を消費する場合、キャッシュ容量を増やしても自動的に有用になるわけではない。

プロセッサは、変換ルックアサイドバッファ、すなわちTLBも維持する。このハードウェアキャッシュは、最近使用された仮想アドレスから物理アドレスへの変換を保存する。データページがPostgresメモリに存在していても、TLBミス後にCPUがその位置を特定するためのペナルティを負うことがある。

巨大ページは、より大きな単位でメモリをマッピングすることでこの負荷を軽減する。Lakebaseは新しい固定コンピュート構成で、明示的な2 MB HugeTLBページを使用する。各巨大ページは標準的な4 KBページの512倍のメモリをカバーし、必要なマッピングエントリ数を同じ倍率で減らす。

PostgreSQLはすでにOSの巨大ページ制御を公開している。そのリソースドキュメントでは、明示的な巨大ページが大きな連続共有メモリ領域に伴うオーバーヘッドを減らせると説明している。この利点は、shared_buffersが非常に大きくなる場合に特に重要である。

仮想化は実装を難しくする。Lakebaseは、ベアメタルホスト上の軽量なゲスト仮想マシン内でPostgresを実行する。そのため、アドレス変換はゲスト層とホスト層の両方をまたぐ。意図した利点を維持するには、巨大ページがホスト、ハイパーバイザー、ゲスト全体で一貫して裏付けられなければならない。

Databricksによると、同社はそのスタック全体に専用の巨大ページサポートを追加した。大規模な固定サイズ仮想マシンは、あらかじめ決められた数の巨大ページを持って起動する。Postgresの初期化後、コンピュートシステムはデータベースが必要としない容量を解放する。

同社は、透過的巨大ページではなく明示的なHugeTLBページを選択した。透過的巨大ページではOSが自動的にメモリを昇格できるが、その動作はベストエフォートである。明示的な予約により、データベース環境はページの可用性とレイアウトをより厳密に制御できる。

Databricksのベンチマークテストでは、huge pagesによりテール読み取りレイテンシが最大約40%低下しました。CPU使用率も最大約30%低下しました。これらは同社の測定値であり、すべてのLakebaseワークロードに対する独立した保証ではありません。

この区別は重要です。huge pagesだけで報告された改善全体を説明できるわけではないためです。2つの変更が同時に導入されました。より多くのデータがshared buffersに保持されるようになったことと、その拡大された領域へのアクセスに必要なページ変換が減ったことです。ワークロードによって、それぞれの仕組みから得られる効果の割合は異なります。

管理者はPostgresを通じて展開済みの設定を確認できます。対象となる80-unit Lakebaseエンドポイントでは、show huge_pagesを実行するとonが返るはずです。これをshared_buffersの値と組み合わせることで、新しい構成がcomputeに反映されたかを直接確認できます。

この仕組みは、通常のPostgresデプロイメントで単にshared_buffersを増やすだけでは十分な答えにならない理由も説明します。データベース用に確保するメモリは、接続、クエリ処理、メンテナンスジョブ、オペレーティングシステムの要件と共存しなければなりません。周辺システムが対応する設計になっていなければ、大きな割り当ては新たな制約を生む可能性があります。

Databricksは仮想マシン、computeイメージ、キャッシュパス、ストレージプロトコルを制御しています。このエンドツーエンドの制御により、huge-pageの予約をPostgresの起動と連携させられます。セルフマネージドのチームでは、これらのレイヤーを個別にチューニングし、自身のワークロードで結果を検証する必要があります。

したがって、Lakebaseのキャッシュの仕組みは「RAMを増やす」ほど単純ではありません。改善は、ホットデータを適切なメモリ領域に配置すること、その領域を効率よくマッピングすること、そしてバッファプール以外に必要なすべての用途のために十分なメモリを確保することに依存します。

本番結果は改善を示すが、普遍的なベースラインではない

Databricksは3つの本番エンドポイントで大幅な改善を報告していますが、公開された事例はプラットフォーム全体の平均的な性能を示すものではありません。

最初の事例では、8月11日06:10 UTC頃に新しい構成が適用されました。Databricksがスループットの代理指標として用いた、1秒あたりにアクセスされたPostgresブロック数は2倍になりました。ストレージのGetPageリクエストは、毎秒約8,000件から約1,500件へ減少しました。

この顧客は、前日、前週、前月と比較して中央値およびp99レイテンシが低下したとも報告しています。リリースでは、基礎となるレイテンシ値、ワークロード定義、クエリ構成、統制された比較環境は示されていません。読者はこの観測結果を標準化されたベンチマークではなく、本番環境での結果として扱うべきです。

2つ目のエンドポイントは8月14日01:30 UTC頃に変更されました。報告されたスループットは約43%増加し、computeキャッシュヒット率は100%近くに達しました。ロールアウト後、リクエストはほぼ完全にshared buffersから処理されました。

3つ目のエンドポイントは8月15日に変更されました。Databricksによると、CPU消費は20コアから4コアへ低下し、キャッシュヒット率は100%近くに達し、測定されたスループットは2倍になりました。CPU使用量の5分の1への低下は目を引きますが、公開記事では外部ワークロードのすべての条件が一定に保たれていたかは明示されていません。

これらの事例を総合すると、もっともらしい仕組みが裏付けられます。より多くのリクエストがDRAMにヒットし、分散ストレージサービスに到達する読み取りは減り、プロセッサはアドレス変換に費やす時間を削減しました。これらの結果は設計変更と整合しています。

ただし、対象となるすべてのcomputeが2倍高速になることを示すものではありません。Databricksは「最大で」という表現を用いており、3つの結果にもばらつきがあります。1つではスループットが43%向上した一方、2つでは以前の測定値のおよそ2倍に達しました。

ワークロード構成は依然として最大の変数です。大きいものの範囲が限定されたワーキングセットに繰り返しアクセスする、キャッシュに敏感なクエリでは効果が大きいはずです。書き込み中心の処理、再利用性の低いスキャン、ロック競合、非効率なクエリ、ネットワークに制約されるアプリケーションロジックは、目に見える改善を限定する可能性があります。

従来のローカルファイルキャッシュも有用な役割を果たしていました。これは当初のshared-buffer割り当てより大きな容量を提供し、多くのストレージレイヤーへのリクエストを回避していました。ホットページをNVMeからDRAMへ移すことで最速経路は改善されますが、この第2層を取り除くと、ワーキングセットが利用可能なメモリを超えたときの挙動は変わります。

Databricksによると、これらの固定computeでは、ミス時はshared buffersから分散ストレージへ進むようになりました。これは、特に大規模または変動するワークロードにとって重要な問題を提起します。メモリヒット率の向上は、拡大されたバッファプールの外にあるページに対するペナルティの増大と共存し得ます。

公開されたエンドポイントは、アクティブデータがより大きな割り当て内に適切に収まったため、恩恵を受けたと考えられます。2つの事例でほぼ100%のヒット率が示されたことは、強い局所性を示唆します。局所性が低いアプリケーションでは、より高速なヒットとリモートミスの間で異なるバランスになる可能性があります。

再起動時の挙動にも注意が必要です。shared buffersは一時的なため、新たに起動したcomputeは通常、ホットなワーキングセットをメモリに持たない状態で始まります。Databricksは、計画的な更新時に頻繁に使用されるデータを再配置する自動キャッシュ事前ウォーミングを別途文書化しています。

事前ウォーミングにより更新後のコールドキャッシュによるペナルティは軽減できますが、再起動中にアプリケーションでは短時間の接続中断が発生する場合があります。ドライバ、プール、リトライロジックはこのイベントを処理しなければなりません。キャッシュの改善によって、接続のレジリエンスが不要になるわけではありません。

独立したベンチマーク結果があれば、この主張はより強固になります。有用なテストでは、データセットサイズ、接続数、クエリ分布、バッファ状態、computeサイズ、レイテンシのパーセンタイルを開示するべきです。また、安定したワーキングセットと変化するワーキングセットの両方で、旧来と新しいキャッシュパスを比較する必要があります。

現時点では、証拠はより限定的な結論を支持しています。Lakebase Postgres computeキャッシュの改善は、Databricksが測定した大規模な本番エンドポイントに対して効果的であるように見えます。別のアプリケーションにおける効果の大きさは、運用者が自身のレイテンシ、ヒット率、CPU、ストレージ読み取りの指標で検証すべき実証的な問題です。

主な対立点は固定メモリとオートスケーリング

今回のリリースはLakebaseのより単純な半分を改善しますが、製品のサーバーレスという約束は、Postgresを再起動せずにキャッシュメモリをリサイズできることにかかっています。

shared_buffers設定は通常、Postgresの起動前に選択されます。データベースは初期化時に共有メモリ領域を確立するため、変更には再起動が必要です。この挙動は、トラフィックを処理しながらメモリ容量を変更するオートスケーリングcomputeと直接衝突します。

固定computeでは、この衝突を回避できます。Databricksは仮想マシンのメモリ容量を把握し、その75%をshared buffersに割り当て、対応するhuge pagesを予約してPostgresを起動します。この割り当ては、マシンの存続期間中変更されずに維持できます。

オートスケーリングエンドポイントは拡張と縮小を行う必要があります。需要が高まると、Postgresはバッファ容量を増やし、ゲストにはそれを効率的にマッピングするために必要な正確な量のhuge pagesが提供されるべきです。需要が低下すると、両方のリソースはアクティブな状態を破損させたり、影響の大きい再起動を強いたりせずに返却されなければなりません。

これは大幅に異なるエンジニアリング課題です。共有メモリには、アクティブなバックエンドが読み取り、変更、ピン留め、または検査しているページが含まれる可能性があります。領域を縮小するには、キャッシュ退避および同時実行中のデータベース活動との安全な調整が必要です。

Databricksは、動的shared buffersと並行してhuge pagesをスケールさせるプロトコルを開発したと述べています。同社は、その実装を第2の技術記事で説明する予定です。また、基盤となる仕組みについてオープンソースのPostgreSQLコミュニティと協力する意向も示しています。

この作業が提供されるまでは、Lakebaseには2つのキャッシュ戦略があります。大規模な固定computeには、拡大されたshared-buffer設計が提供されます。オートスケーリングcomputeは、保守的にサイズ設定されたshared buffersとローカルファイルキャッシュの既存の組み合わせに引き続き依存します。

この分離は、製品の位置付けに圧力をかけます。固定容量は現在最も明確な性能改善を提供する一方、オートスケーリングはサーバーレスデータベースに求められる柔軟性を提供します。顧客はまだ、同じcomputeモードで両方の特性を得られると想定できません。

これは、すべてのデプロイメントにおいてオートスケーリングが劣ることを意味するわけではありません。変動的または断続的なアプリケーションでは、可能な限り低いキャッシュレイテンシよりも、scale-to-zeroと弾力的な容量を重視する場合があります。安定してメモリ集約的な本番サービスでは、予測可能な固定リソースが好まれるかもしれません。

この判断はワークロードの成長にも依存します。固定computeでは、運用者があらかじめ十分な容量を選択する必要があります。オートスケーリングはトラフィック変動を吸収できますが、現在のキャッシュパスでは、ワーキングセットが小さなshared-buffer割り当てを超えると、より多くのヒットがローカルNVMeを経由する可能性があります。

これがLakebaseキャッシュ性能における真の競争上の試金石です。他のマネージドPostgresサービスも、分散耐久性、ローカルキャッシュ、レプリカ、弾力的なリソース管理を組み合わせています。アーキテクチャの詳細は異なるため、見出しのベンチマーク数値だけで明確な製品ランキングを支持できることはほとんどありません。

Databricksは代わりに、ストレージの分離が対象ワークロードに回避可能なペナルティを課さないことを示さなければなりません。動的shared buffersを実現すれば、Lakebaseはステートレスcomputeモデルを維持しつつ、より多くの弾力的なメモリをPostgresの直接制御下に置けます。

アップストリームとの協力は、Lakebaseを超えて影響を広げる可能性があります。動的なバッファサイズ設定は、割り当てメモリが時間とともに変化するコンテナ化および弾力的なPostgres環境に関係します。しかし、Databricksは発表で説明したコード、レビュー状況、リリースパスをまだ公開していません。

この不確実性は明示したままにすべきです。同社は方向性を示し、オートスケーリングのプロトコルが存在すると述べています。オートスケーリングshared buffersについて、リリース日、対応compute範囲、本番測定値は提供していません。

したがって、固定computeのロールアウトは改善であると同時に予告編でもあります。これは、安定したメモリ条件下でキャッシュ配置とhuge-pageの仕組みを検証します。次の段階では、可用性や予測可能な性能を犠牲にせず、これらの仕組みが変化するマシンに追随できることを証明しなければなりません。

Lakebaseユーザーが今測定すべきもの

重要な問いは、公開されたベンチマークが印象的かどうかではなく、対象ワークロードが新たなミスペナルティを生じさせずに高速化するかどうかです。

対象ユーザーはまず構成を確認できます。show shared_buffersは現在のPostgresバッファ割り当てを示し、show huge_pagesは明示的なhuge pagesが有効かどうかを報告します。同社の事例に基づくと、80-unit Databricksエンドポイントでは120 GBとonが表示されるはずです。

構成だけでは価値を確立できません。チームは、同等のトラフィック期間にわたり、キャッシュヒット率、ストレージのGetPageアクティビティ、CPU消費、スループット、p50およびp99クエリレイテンシを比較するべきです。比較では、デプロイ、データ増加、メンテナンス、アプリケーション変更を考慮する必要があります。

キャッシュヒット率には文脈が必要です。100%近い比率は、アクティブなワーキングセットがメモリに収まっていることを示す場合があります。しかし、スループットとレイテンシを伴わずに評価すると、リクエストコスト、クエリ頻度、ワークロード構成の違いを隠す可能性もあります。

ストレージ読み取りは別の直接的なシグナルを提供します。減少は、pageserversに到達するのではなく、より多くのページがPostgres内に保持されていることを示唆します。Databricksは最初の事例で、毎秒約8,000件から1,500件への減少に基づき、GetPageリクエストが約5.3分の1になったと報告しました。

CPU測定は、huge pagesとディスクキャッシュ処理の回避による効果を明らかにできます。ただし、CPU使用量の低下が最も有用なのは、安定または増加したスループットと組み合わされる場合です。静かな期間にはCPUと完了した処理の両方が減少する可能性があり、効率向上を反映しているとは限りません。

チームは再起動時とウォームアップ時の挙動も確認すべきです。計画的な更新ではコンピュートの再起動が発生しますが、Databricksによれば通常は数秒で完了します。こうした時間帯の接続リトライやテールレイテンシをテストすることで、定常状態のチャートでは見落とされる運用上の影響を明らかにできます。

具体例として、アクティブなインデックスと頻繁にアクセスされる行が数十GBを占めるトランザクションアプリケーションを考えます。従来の構成では、そのうち共有バッファに保持できるのはごく一部に限られていました。DRAMに余力があっても、多くのヒットはローカルNVMeキャッシュに到達していました。

更新後は、そのワーキングセットのほぼ全体が拡張されたバッファプールに収まる可能性があります。チームはストレージリクエストの減少、読み取りレイテンシの低下、CPUオーバーヘッドの削減を期待すべきです。これらの指標が改善しない場合は、別のボトルネックが支配的である可能性が高いでしょう。

AIエージェントサービスは、もう一つのシナリオを示します。会話状態、ツールの実行結果、ジョブのステータス、ベクターメタデータなどをPostgresに保存しているかもしれません。頻繁に再利用されるページがメモリに残ることで、突発的に同時読み取りが増えた場合にも恩恵を受けられますが、バックエンドプロセスへの負荷は依然として接続数とクエリパターンによって決まります。

この種の変更を評価するエンジニアに必要なのは、個別のスクリーンショットではなく共有可能な証拠です。検索可能なエンジニアリング・ナレッジベースを活用すれば、ベンチマーク条件、クエリプラン、構成スナップショット、ロールアウト時の観察結果を保存し、後から比較できます。

評価には失敗ケースも含めるべきです。ワーキングセットが拡張後の共有バッファを超える場合、固定コンピュートには従来のような中間層としてのローカルファイルキャッシュが存在しません。コールドスタート、大規模スキャン、ワーキングセットの急変時にレイテンシを測定することで、リモートミスがより顕在化するかを確認できます。

これらの確認は、企業が掲げる主張を受け入れることも否定することも求めません。提案された仕組みを観測可能なシグナルへと置き換えるものです。同等の負荷条件で、共有バッファにヒットする読み取りが増え、CPU使用率とテールレイテンシが低下するなら、そのワークロードでは更新が機能しています。

スループットが横ばいのままであれば、Lakebaseに原因を求める前に、ロック待機、アプリケーションネットワーク、クエリプラン、インデックス、書き込み負荷を調べるべきです。キャッシュの変更だけで、データベースレイテンシのすべての原因を解決することはできません。

キャッシュ再設計の重要性を左右する3つのシグナル

オートスケーリングへの提供、独立したワークロードの検証結果、そして上流PostgreSQLの進展が、これがLakebase全体の利点となるかを決定します。

最初のシグナルは、オートスケーリングコンピュート向けの動的共有バッファの本番リリースです。Databricksは、巨大ページのバッキングを適切なサイズに保ちながら、共有バッファ容量をメモリに合わせて拡張・縮小できることを示す必要があります。対象条件、ロールアウトの挙動、運用上の制約を開示したリリースは、同社のアーキテクチャ上の主張を強めるでしょう。

本番環境での測定結果も、そのリリースに伴うべきです。有用な比較は、オートスケーリングを無関係な固定ベンチマークと比べることではありません。動的バッファ導入の前後で同じ弾力的なワークロードを比較し、スケールアップ、スケールダウン、キャッシュヒット率、CPU使用率、p99レイテンシを含めることです。

オートスケーリングが、破壊的な再起動なしに同等のキャッシュ効率を実現すれば、現在の分析はより強固になります。これは、分離型のPostgresが、弾力的なコンピュートとエンジン管理の大容量メモリキャッシュを両立できることを示します。長期的な遅延があれば、最速の経路は固定容量に限定されたままとなります。

2つ目のシグナルは、より幅広いベンチマークの証拠です。Databricksは有利な本番事例を3件公開していますが、ユーザーには異なるワーキングセット規模やクエリパターンにわたる結果が必要です。独立したテストには、読み取り中心のトランザクション、読み取りと書き込みの混在、高接続数、コールドスタート、利用可能なDRAMを超えるワークロードを含めるべきです。

一貫した改善を示す証拠は、主張されている仕組みを裏付けます。結果が大きく変動してもリリース自体が無効になるわけではありませんが、恩恵を受ける可能性が高いアプリケーションの範囲は狭まります。ローカルディスク層の廃止後にキャッシュミスで性能低下が見られる場合は、より注意深い検討が必要です。

3つ目のシグナルは、オープンソースPostgreSQLにおける目に見える進展です。Databricksは動的共有バッファについて上流コミュニティと協力する計画だとしています。具体的な提案、パッチ、技術的議論、レビュアーからのフィードバックにより、ソリューションのどの程度がPostgres本体に属するべきものかが明らかになります。

上流で受け入れられれば、設計はより幅広い技術的検証を受け、単一ベンダーの枠を超えて利用可能になります。また、弾力的なクラウド環境と固定マシンを前提に設計されたPostgres設定との長期的な隔たりを縮める可能性もあります。

この取り組みを上流化できなくても、Databricksがプラットフォーム固有の実装を提供することは妨げられません。しかし、外部の人々にとっては、互換性、保守性、可搬性の評価がより難しくなります。

Lakebase Postgresコンピュートのキャッシュ改善は、すでに選定された固定コンピュートで測定可能な成果を生んでいます。より重要な試金石は、ストレージ分離がもたらす弾力性を損なわずに、Databricksがキャッシュを動的にできるかどうかです。

対象となるエンドポイントを運用するチームにとって、次の行動は明確です。設定を確認し、安定したベースラインを記録し、ロールアウト後に実際のワークロード指標を比較してください。オートスケーリングの利用者は、同じ改善が適用されると判断する前に、2回目のエンジニアリングリリースを注視すべきです。現在のアプリケーションにとってより重要なのは、固定メモリでの性能でしょうか、それとも需要に応じて容量を拡張できる自由でしょうか。