6月25日、Databricksが「What To Look For in a Serverless Database for AI Applications」と題した記事を公開した。AIアプリケーション向けサーバーレスデータベースを選定する際に評価すべき技術要件と実践的なチェックリストを詳述した内容だ。特に「サーバーレス」の定義が製品によって大きく異なる点、コネクションモデルの違いがエージェントワークロードに直撃する理由、そして本番DBへの書き込みリスクを回避する「データブランチング」の仕組みが読みどころとなっている。
AIエージェント時代に「サーバーレスDB」が基本インフラになりつつある理由
AIアプリのトラフィックは予測困難だ。エージェントが突発的に大量クエリを発行し、モデル開発中はほぼアイドル状態が続く。従来のプロビジョニング型DBでは、この不均一な負荷に対してコストと管理の両面で無駄が生じやすい。Databricksはこうした背景から、AIワークロードに特化したサーバーレスDBの選定基準を整理した。
エンジニアが見落としがちな「サーバーレス」の定義問題
まず押さえておきたいのが、「サーバーレス」と名乗っていても、アーキテクチャ上の意味が製品によって異なるという点だ。
- 自己管理型DB：完全なコントロールを持つが運用負担が高い
- マネージドDBaaS：クラウドプロバイダーに運用を委ねる
- サーバーレスDB：自動スケーリング＋従量課金＋最小限の管理
本来のサーバーレスはコンピュートとストレージがアーキテクチャ的に分離されており、それぞれが独立してスケールし、それぞれの層の使用量のみが課金される。一方で「サーバーレス」と称しながら、従来型の結合アーキテクチャにオートスケーリングと従量課金を載せただけの製品も存在する。こうした製品はスケールダウンの限界が低く、アイドル時のコスト効率に劣る。
ベンダー評価時に確認すべき質問は「コンピュートがゼロにスケールした際にストレージは独立して維持されるか？」だ。
AIワークロードで特に重要な3つの評価軸
Databricksはチェック項目を12点挙げているが、AIアプリにとって特に重要なのは以下の3点だ。
1. コネクションモデル
AIエージェントやサーバーレス関数は、同時に数千のDB接続を開くことがある。従来のTCP接続モデルではこれが即座にボトルネックになる。主な接続モデルは3種類ある。
- Connection-per-request（レガシー）：リクエストごとに接続を開閉する。スケール時に非効率
- TCP + コネクションプーラー：少数の永続接続を多クライアントで共有する。高並列アプリの標準手法
- HTTP / Data API：永続TCP接続不要でステートレスなワークロードに適する
重要なのは、コネクションプーリングがプラットフォームに組み込まれているかを確認することだ。外部プーラーを別途管理するのは運用の複雑さを増し、別のボトルネックになりうる。
2. コールドスタートのレイテンシ
スケールゼロは大幅なコスト削減をもたらすが、コンピュートが再起動する際の「コールドスタート」遅延が発生する。レイテンシ要件の厳しいAIワークロードでは、最小コンピュートを一定量維持するトレードオフが必要になる場合もある。評価時は「実際のワークロードでのウォームアップ時間の公開データ」をベンダーに求めること。口頭での説明ではなく、数値で確認することが重要だ。
3. データブランチング（安全な実験環境）
AIエージェントはデータを読むだけでなく、書き込む。顧客レコードの更新やスキーママイグレーションを本番データに対してテストすると、他のワークフロー全体が依存するデータセットを破壊するリスクがある。
データブランチングはこの問題を解消する。データの完全コピーを作成するのではなく、親DBとストレージを共有しつつ変更分のみ書き込む独立した環境を即座に生成する。エージェントは本番相当のデータで自由に実験し、タスク完了後にブランチを破棄できる。コピーにかかるコストも時間もなく、本番への影響もゼロだ。
残りの評価項目：実践的チェックリスト
その他の評価項目をまとめると以下のとおりだ。
- オープン標準：PostgreSQL互換など標準ワイヤープロトコルを採用しているか。プロプライエタリAPIはベンダーロックインのリスクがある
- 真のスケールゼロ：最小課金単位が実際にゼロになるかどうか
- 価格の透明性：コンピュート・ストレージ・I/Oを分離した課金ダッシュボードがあるか。ウォームアップ予約容量やリードレプリカ、クロスリージョン転送などの隠れたコストが存在する場合がある
- p95/p99レイテンシ：平均応答時間だけでなく、最も遅い1〜5%のリクエストのレイテンシをスケールアップ時の挙動も含めて確認する
- セキュリティとCMK：暗号化・VPCネットワーク分離・IAM統合・監査ログのほか、自動ポーズ中のカスタマー管理暗号キー（CMK）の振る舞いに注意が必要だ（キーが失効するとコンピュート再開時にDBにアクセスできなくなる）
- ガバナンス統合：行・列レベルのアクセス制御とデータリネージ追跡が分析・AIインフラ全体に一貫して適用できるか
- AIネイティブ機能：ベクトル検索、エンベディングの構造化データとの同一DB格納、フィーチャーストア連携
- 信頼性とRPO/RTO：マルチAZレプリケーション、ポイントインタイムリカバリ、自動フェイルオーバー。レプリカはプライマリとストレージを共有するタイプか（独立コピーより低レイテンシかつ低コスト）
DatabricksのLakebaseと、この記事がなぜ自社製品で締めるのか
Databricksは自社製品としてLakebaseを提供している。AIアプリ・エージェント向けにフルマネージドのサーバーレスPostgresDBとして構築されており、データレイクハウスと同一のストレージ・ガバナンス層上に位置する。ベクトル検索、Unity Catalogによる統合ガバナンス、Databricksのモデルサービングインフラとの連携を特徴として挙げている。
本記事はDatabricks自身が公開した製品ブログであり、チェックリストの設計がLakebaseの強みと合致している点は念頭に置く必要がある。ただし、記事が示す評価軸——コンピュート・ストレージ分離、組み込みコネクションプーリング、データブランチング——は、製品選定において製品を問わず有効な観点だ。
※編集部の考察：同種のサーバーレスPostgres製品としてはNeonやPlanetScale（MySQL系）、AWS Aurora Serverless v2などが市場に存在するが、Databricksのアプローチはレイクハウス統合とガバナンスの一元化を差別化軸としている点が特徴的だ。純粋なOLTPのみを必要とするケースと、分析・AI推論パイプラインと横断的に連携したいケースとでは、最適な選択肢が異なりうる。
詳細はWhat To Look For in a Serverless Database for AI Applicationsを参照していただきたい。
