10月9日、Databricksが「Lakebase and Agentic SDLC: Branching Databases for Coding Agents」と題した記事を公開した。コーディングエージェントが複数並列で動く時代になった。しかし、コードのブランチ管理はGitで解決できても、データベースの分離はいまだに未解決の課題として残っている。複数のエージェントが同一の開発用DBにスキーマ変更を加えようとすれば、競合・破壊・本番データへのリスクが生じる。これはもともと開発者が抱えていた問題だが、エージェントは人間より速く、並列で動くため被害が大きい。
DatabricksのPostgres互換サービス「Lakebase」は、この問題をGitのブランチ管理と同じ発想でデータベースに適用することで解決しようとしている。LakebaseはDatabricks Data Intelligence Platformの一部として2025年に発表され、現在パブリックプレビュー段階にある。NeonやPlanetScaleといったサービスもDBブランチング機能を持つが、LakebaseはDatabricksのLakehouseアーキテクチャと統合されている点が異なる。Delta Lakeとの直接的な連携については現時点で明示されていないが、Databricksのデータ基盤と同一プラットフォーム上で動作するPostgresサービスとして位置付けられている。
データベースを1秒以下でブランチする
Lakebaseの核心はデータベースブランチングだ。サイズに関わらず、1秒未満でデータベース全体をブランチできる。コピーオンライト方式を採用しているため、ブランチは親ブランチのデータを共有しつつ、差分が生じた分だけストレージを消費する。さらにスケールトゥゼロ対応なので、使われていないブランチはコンピュートコストがかからない。多数のエージェントを同時実行する環境では、この特性は特に重要になる。
Figure 1: エージェントとPRそれぞれに、独立したエフェメラルDBが割り当てられる開発ループ
エージェント1体につき、DBブランチ1本
並列コーディングエージェントへの対応として、記事ではGitのworktree機能とLakebaseブランチングを組み合わせたワークフローを紹介している。
- Gitワークツリー（
git worktree）: 各エージェントが独立したディレクトリとコードブランチを持つ。ファイルレベルの競合を防ぐ仕組み。 - Lakebaseブランチ: 各ワークツリーに対応するDBブランチを自動で払い出す。
具体的には、リポジトリにpost-checkoutフックを仕込むことで、ワークツリー作成のたびに自動でDBブランチが生成される。Claude Codeを使った例では次のような流れになる：
- エージェントが
claude --worktree feature-123を実行 - Gitが
feature-123ブランチ用のワークツリーを作成 - post-checkoutフックが自動で発火し、DBブランチを作成
- エージェントは独立したコードディレクトリと独立したDBを持った状態で作業開始
Figure 3: GitワークツリーとLakebaseブランチで分離された、並列Claudeセッション
エージェントが作業を終えてPRを作成したら、ワークツリーとDBブランチの両方を破棄する。
ひとつ注意点がある。Gitと異なり、LakebaseのブランチはマージしてメインDBに取り込む操作は行わない。コピーオンライト方式の性質上、ブランチ作成後に親子双方が独立して変化した場合、どちらの変更をどの順序で正とするかを自動追跡することが技術的に困難なため、bidirectionalな変更追跡・reconciliationは現実的でない。その代わり、スキーマ変更はコードとして追跡し、Drizzle・Flyway・Liquibase・Alembicなどのマイグレーションツールで親ブランチに適用する設計になっている。
PRごとにエフェメラルDBを自動生成するCI
PRが作成されると、GitHub Actionsを使ってPRごとに本番DBの子ブランチを自動生成する。このブランチをそのPR専用のDB環境として使い、テスト・プレビュー環境のデプロイ・レビューをすべてここで行う。本番DBから派生しているため、マイグレーションを本番適用前に実際のスキーマで検証できる。
サンプルのGitHub Actionsワークフローの流れは以下のとおりだ：
- PRが
mainにオープンされる - CIがLakebase CLIを呼び出して
pr-123のようなブランチを作成 - マイグレーションツールが専用DBブランチに対して実行される
- プレビューアプリがそのブランチの接続文字列を向く形でデプロイされる
- スキーマdiffがPRコメントとして自動投稿される（どのテーブル・カラム・インデックスが変わったか一目瞭然）
- レビュワーがコードとDB変更の両方を確認
- PR のクローズまたはマージ後にCIがブランチを削除
Figure 4: PR上に自動投稿されるスキーマdiffコメント
スキーマdiffが自動でPRコメントに出てくる体験は、レビュワーにとって実用的な改善になる。コードのdiffと同じ感覚でDB変更を確認できる。
まとめ
記事が提示するLakebase開発ループの構造はシンプルだ：
- エージェントごとにDBブランチ
- PRごとにDBブランチ
- 本番検証用にDBブランチ
Gitがコードの分岐を当たり前にしたように、Lakebaseはデータベースの分岐を開発フローの標準にしようとしている。コーディングエージェントの並列実行が増えるにつれ、この種のDB分離の仕組みは今後の開発インフラの重要な構成要素になっていく可能性がある。サンプルコードはGitHubリポジトリで公開されており、GitHub Actionsのワークフロー例も含まれている。
なお、記事ではサンプルリポジトリには実装されていないものの、有用なワークフローとして以下も挙げられている（本筋のエージェント・CIフローとは別の発展的用途として参考にしてほしい）：
- バグ再現: バグ発生直前の時点で本番DBのブランチを作成し、実データで安全に調査・再現する
- 本番マイグレーションの事前検証: 本番DBのブランチでマイグレーションとテストを走らせ、問題がなければ本番に昇格させる
これらは本番データを直接触らずに済むため、Unity Catalogのデータマスキングと組み合わせることで、PII等の機密データを扱うチームにも適用しやすい。
詳細はLakebase and Agentic SDLC: Branching Databases for Coding Agentsを参照していただきたい。
