Lakebase とは — Databricks のサーバレス Postgres

Lakebase は、Databricks が 2026 年に GA (一般提供開始)したサーバレス Postgres データベースです。Aurora / Cloud SQL / Cosmos DB の代替を狙う本格 OLTP サービスでありながら、Unity Catalog 経由で Lakehouse のデータと統合できる点が決定的に差別化されています。 AI エージェントのバックエンド、SaaS アプリケーションの本番 DB、本番データの分析活用など、幅広い用途が想定されています。

本記事では、Lakebase の全機能・料金体系・他のマネージド Postgres との比較・Lakehouse Sync の挙動・ 本番運用のベストプラクティス・認定試験での出題予想までを、2026 年最新版で完全解説します。

Lakebase とは何か

Lakebase は、Databricks Data Intelligence Platform に統合されたサーバレス Postgresサービスです。 2026 年 GA で「Lakebase Autoscaling」と「Lakebase Provisioned」が単一 UI に統合され、以下の機能が完備されました。

• Autoscaling: ワークロードに応じて自動でスケールアップ/ダウン
• Scale-to-zero: 待機時間中はゼロまで縮退、料金ゼロ
• Instant Branching: 本番 DB を瞬時にコピーして検証環境を作る
• 自動バックアップ + Point-in-Time Recovery (PITR)
• ストレージ最大 8TB / インスタンス
• Postgres 17 ベース: 最新の OSS Postgres と完全互換
• pgvector 標準搭載: AI 検索 / RAG パターンに対応
• 複数 Azure リージョン対応: グローバル展開可能

単なるマネージド Postgres ではなく、Lakehouse とのネイティブ統合が最大の特徴です。

なぜ Lakebase が必要なのか

従来、企業は OLTP (取引処理) と OLAP (分析処理) を別々のシステムで運用してきました。 OLTP は Aurora / Cloud SQL / Cosmos DB、OLAP は Snowflake / BigQuery / Databricks Lakehouse、というように。

この分離には深刻なデメリットがあります。

• データのコピーが必要: DMS / Glue / Snowpipe 等で OLTP → OLAP に常時 ETL が必要
• 遅延が発生: 数分〜数時間の遅延で「リアルタイム分析」ができない
• ガバナンスが分散: アクセス制御を 2 つのシステムで二重管理
• 運用コストが倍: 別々のサービスのライセンス + 専門知識が必要
• AI ワークロードに不向き: AI エージェントは OLTP の状態管理 + Lakehouse の知識ベースの両方を必要とする

Lakebase はこれらすべてを解消します。OLTP データが Lakehouse Sync で Delta テーブルに自動レプリケートされるため、 OLTP データを書いた瞬間に分析クエリで使える。これが Lakebase の真の価値です。

料金体系 — Autoscaling と Always-On

Lakebase の料金は Capacity Unit (CU) 時間あたりの DBU 換算 + ストレージ別建てです。 2 つの課金モデルが選択できます。

Autoscaling プラン (完全従量制)

最小・最大の自動スケール範囲と scale-to-zero のタイムアウトを設定。 待機時間中は料金ゼロになるため、開発・検証・低負荷ワークロードに最適。

• 料金: 使用 CU 時間 × DBU 単価 + ストレージ
• scale-to-zero: 設定したタイムアウト経過後、自動で停止
• 復帰時間: 数秒〜数十秒
• 典型用途: 開発環境、検証環境、社内ツール、PoC

Always-On プラン (基準容量で 25% 割引)

本番常時稼働向け。基準容量分は 25% 値引き、超過分は autoscaling で吸収。 長期コミットメント不要で、Aurora の Reserved Instance 相当の割引が手軽に得られます。

• 料金: 基準容量 (25% off) + 超過分 (定価)
• 常時稼働: scale-to-zero しない
• autoscaling: スパイクは自動で吸収
• 典型用途: SaaS 本番 DB、社内基幹システム、AI エージェントのバックエンド

ストレージ料金

ストレージは別建てで、Postgres データ + WAL (Write-Ahead Log) + バックアップが課金対象。 Aurora と同等レンジで、明示的に予約購入の概念なし。

Aurora / Cloud SQL / Cosmos DB との徹底比較

vs Amazon Aurora PostgreSQL

• Aurora の優位: 既存 RDS ユーザーが移行容易、豊富なリージョン対応、Aurora Serverless v2 の成熟度
• Lakebase の優位: Lakehouse Sync によるゼロ ETL 分析、Unity Catalog 統合のガバナンス、AI エージェント特化機能、Postgres 17 即時対応
• 選択基準: AWS 中心で分析が別 (Redshift / Snowflake) なら Aurora、Databricks Lakehouse を分析基盤にしているなら Lakebase 一択

vs Google Cloud SQL for PostgreSQL

• Cloud SQL の優位: BigQuery との連携 (Federated Query)、GCP エコシステム内の親和性
• Lakebase の優位: マルチクラウド対応 (AWS / Azure / GCP すべてで動く)、scale-to-zero、Lakehouse Sync
• 選択基準: GCP 完結でデータ量が中規模なら Cloud SQL、マルチクラウドや Databricks 中心の組織は Lakebase

vs Azure Cosmos DB for PostgreSQL (Citus)

• Cosmos DB の優位: 分散 Postgres による水平スケール (Citus)、Azure 内の他サービス連携
• Lakebase の優位: Lakehouse 統合、Postgres 17 対応 (Cosmos は 16)、scale-to-zero
• 選択基準: 数十 TB 規模で水平分散が必要なら Cosmos DB、〜 8TB かつ Lakehouse 連携重視なら Lakebase

vs Neon / Supabase

• Neon / Supabase の優位: 個人開発・スタートアップ向け料金、コミュニティとエコシステム
• Lakebase の優位: エンタープライズグレードのガバナンス、Unity Catalog、Lakehouse 統合、AI 向け最適化
• 選択基準: 個人〜小規模スタートアップは Neon、エンタープライズ・既存 Databricks ユーザーは Lakebase

Lakehouse Sync の仕組み

Lakehouse Sync は 2026 年 Public Preview の機能で、Lakebase の Postgres テーブルをUnity Catalog 管理の Delta テーブルに、CDC (Change Data Capture) で低遅延レプリケートします。

従来の OLTP → OLAP データパイプラインは以下のようなものでした。

1. Aurora の WAL を読み取る Debezium / DMS の設定
2. Kafka / Kinesis にイベント送信
3. Snowpipe / Glue / Spark で取り込み
4. Delta テーブル / Iceberg テーブルにマージ
5. BI / ML が分析クエリ

各ステップでインフラ構築・運用・コストが発生し、データ遅延は 数分〜数時間。

Lakehouse Sync ではこれらすべてが 1 つのトグルを ON にするだけで実現します。

• Lakebase Project 設定で「Lakehouse Sync」を有効化
• 同期対象のテーブルを選択
• 同期先の Unity Catalog Catalog / Schema を指定
• 数秒〜数十秒の遅延で Delta テーブルに自動反映

これにより、注文テーブルや在庫テーブルが書き込まれた直後に、ML モデルや BI ダッシュボードでリアルタイム集計できます。

AI エージェントのバックエンドとしての Lakebase

AI エージェントの状態管理は、従来の DB では設計が難しい領域でした。理由は以下の通り。

• スケールが予測不能: バーストワークロードへの即時対応が必要
• 状態保持が必須: 会話履歴、ツール実行ログ、ユーザーコンテキスト
• 知識ベースとの連携: Lakehouse 上の Vector Search / RAG ドキュメントへのアクセス
• 低レイテンシ書き込み: ユーザー応答時間に直結

Lakebase はこれらすべてに最適化されています。

• scale-to-zero + 自動スケーリングでバースト対応 + アイドル時のコストゼロ
• Postgres + pgvectorで状態管理と意味検索が同じ DB で完結
• Lakehouse Syncで会話履歴を分析用に Delta テーブル化、後続の改善に活用
• 低レイテンシ: マネージド Postgres と同等の応答時間

Anthropic / OpenAI API を呼ぶ AI エージェントの状態保持に、現在最も洗練された選択肢の 1 つです。

使い始め方

Lakebase は Azure Databricks / AWS Databricks の Workspace から数クリックで開始できます。

1. Workspace のサイドバーから「Lakebase」を選択
2. 「Create Project」で新規 Lakebase プロジェクトを作成
3. Autoscaling か Always-On を選択
4. 初期スペック (Capacity Unit 範囲 + ストレージ) を設定
5. 接続情報 (host / port / password) が発行される
6. psql / pgAdmin / アプリから標準の Postgres プロトコルで接続

新規 Lakebase Autoscaling プロジェクトでは Postgres パスワード認証がデフォルト無効になっており、 OAuth / Workspace ID ベースのセキュア接続が推奨されます。パスワード認証を使う場合はプロジェクト設定で明示的に有効化が必要です。

本番運用のベストプラクティス

容量設計

Autoscaling の最小 CU は実トラフィックの底値、最大 CU はピークの 2 倍を目安に設定。 scale-to-zero タイムアウトは開発で 5 分、本番で 30 分が標準。

バックアップ戦略

自動バックアップは標準で 7 日間の PITR が可能。 本番では Instant Branching でリリース前のスキーマ変更を検証してから適用するのが定石。

認証戦略

パスワード認証は無効のまま、OAuth + Service Principal で接続。 各アプリ・各環境に Service Principal を発行し、最小権限の原則で運用。

監視

Databricks の System Tables から接続数・クエリパフォーマンス・容量使用率を取得。 Cloudwatch / Azure Monitor 連携で既存の監視基盤に統合可能。

コスト最適化

開発環境は Autoscaling + 短いタイムアウト (5 分) でアイドル時のコストをゼロに。 本番は Always-On で基準容量 25% 割引を取りつつ、autoscaling でスパイクを吸収。

認定試験での出題予想

2026 年 5 月時点で、Databricks Data Engineer Associate / Professional の公式 Exam Guide に Lakebase は未掲載です。 ただし以下の理由から、2026 年後半〜 2027 年の改定で出題対象になる可能性が高いと予想されます。

• Databricks 自身が「Lakehouse + OLTP」をプラットフォームの目玉として推進中
• 2026 FabCon で大々的に GA 発表
• 既存試験で Unity Catalog / Delta Sharing 等の上位機能が頻出していることから、Lakehouse Sync も範囲入りが自然

先取り学習のおすすめトピック:

• Lakebase の Autoscaling と Always-On の違い・選び方
• Lakehouse Sync の同期方式と遅延特性
• Lakebase が解決する「OLTP × OLAP 分離」問題
• AI エージェント用途での Lakebase の優位性

よくある質問