社内AIが止まる一秒
AIが賢いのに、なぜ画面で待たされるのでしょうか。理由の一つは、AIが読むデータの場所にあります。
Databricksが発表したLakebase Postgresのcompute cache改善は、そこに効きます。AIが賢くても、データが遠いと仕事は遅いです。
答えの近くにデータを置く
Lakebase Postgresは、Databricksの中で動くPostgres系データベースです。Databricksは、lakehouse（保存と分析をまとめる基盤）の中のserverless Postgres engineと説明しています。
AIアプリは、モデルだけで動くわけではありません。顧客情報、社内文書、履歴、承認状態のようなデータを読みます。
Databricksの構成では、storage layer（保存する層）が正式な記録を持ちます。compute node（計算する側）は状態を持たず、メモリをキャッシュとして使います。
今回の改善は、このcompute側のキャッシュを速い場所へ寄せるものです。よく読むデータを近くに置くほど、返事は軽くなります。
提供条件は大きな固定サイズから
| 項目 | 発表で確認できる内容 |
|---|---|
| 発表日 | 2026年9月10日 |
| 対象 | 固定サイズcomputeのCU 80以上 |
| 提供時期 | 発表時点で提供中 |
| 料金 | 発表本文には書かれていない |
| 未完了範囲 | autoscaling computeは対応作業中 |
発表時点での主対象は、固定サイズcomputeのCU 80以上です。すべてのautoscaling（負荷に応じて自動増減する仕組み）へ一気に広がった話ではありません。
この対象ではlocal file cache（二段目のキャッシュ）を無効にします。shared buffers（Postgres内の高速な記憶領域）をDRAMの75%に設定します。
仕事の画面で効く変化
Databricksの開発者ページでは、企業データ上で低遅延のアプリやagentを作れると説明しています。Databricks Appsは、built-in authとgovernanceを持つmanaged serverless runtimeです。
用途例は、ふだんの仕事に近いものです。データベースの待ち時間は、こうした画面の反応にそのまま出ます。
・社内知識assistantは、文書や履歴を読みます。
・customer support copilotは、顧客対応の文脈を読みます。
・analyst productivity toolsは、分析に必要なデータを読みます。
・approval and routing systemsは、承認や振り分けの状態を更新します。
数字を盛らずに読む
Databricksは、性能の説明を本番endpointの例で示しました。大きなcomputeで、スループットと遅延の両方に改善が出ています。
2026年8月11日の例では、Postgres blocks per secondが2倍になりました。storage GetPage/sは約8Kから約1.5Kへ下がりました。
2026年8月14日の例では、スループットが約43%上がりました。compute cache hit rateはほぼ100%です。
別のワークロードでは、CPU使用が20 coresから4へ下がりました。同時に、スループットは2倍になりました。
autoscalingへの持ち越し
Databricksは、autoscaling Postgres computesへ大きなshared buffersを広げる作業中だと書いています。ここは、今回の発表でまだ残った部分です。
理由は分かりやすいです。autoscalingでは、増える時も縮む時もメモリ量が変わります。
Databricksはdynamic shared buffers（動的に大きさを変える記憶領域）とhuge pages（大きな単位のメモリ管理）を連動させる方針です。ここまで進むと、固定サイズだけの改善ではなくなります。