本記事はシリーズの第2部であり、20年後の進化的データベース設計手法を再検討します。従来、データベース変更は共有リソースの制約に直面していましたが、Databricks Lakebaseのコピーオンライト分岐技術により状況が一変しました。テラバイト規模の本番データベースの分岐を1秒で作成でき、初期ストレージコストはゼロです。これにより、これまで理想的に過ぎたプラクティス（「全員が自分のデータベースインスタンスを持つ」）が現実のものとなりました。
記事はまず、2003年に提唱された7つのオリジナルプラクティスを振り返ります：DBAと開発者の緊密な協力、すべてのデータベース成果物のバージョン管理、すべての変更をマイグレーションとして扱う、各自が独自のデータベースインスタンスを持つ、開発者が継続的に統合する、すべての変更をリファクタリングとする、開発者がオンデマンドで更新できる。これらうち5つは技術的制約により完全には実装されていませんでした。例えば、DBAレビューは同期的でボトルネックに、独立インスタンスはコスト高に、CI/CDでは共有ターゲットデータベースに依存し隔離性が欠如していました。
Lakebaseのアーキテクチャは、コンピュートとストレージを分離し、データをオブジェクトストレージ（S3など）に永続化します。PostgreSQLエンジンは独立したコンピュート層として動作します。分岐操作は共有ストレージへの新しいポインタを作成するだけであり、書き込み時にのみ差分ページが保存されるため、データサイズに依存しません。この特徴により、プラクティス4のコスト障壁が取り除かれ、開発者ごと、PRごと、実験ごとに独立したデータベースインスタンスが可能になりました。モック層やインメモリデータベース（H2、SQLiteなど）、ローカルデータベースのDockerコンテナは不要になり、DBAのチケットキューも大幅に短縮されます。
これらの能力に基づき、2026年の新しいプラクティスが提案されています：DBAはPR上のスキーマ差分を非同期でレビュー（プラクティス1の強化）；すべてのデータベース成果物（スキーマ差分やマイグレーションテスト結果を含む）をバージョン管理（プラクティス2の強化）；マイグレーションスクリプトは冪等性を必須；独立インスタンスをPR単位で細粒度に提供；継続的インテグレーションをPRレベルで自動実行；リファクタリングを様々な規模の環境で事前試行；オンデマンド更新は1秒で完了し他者に影響なし。さらに、破壊的テストをデフォルトオプションとし（爆発半径ゼロ）、A/Bバリアントを並行ブランチでプロトタイピングし、統一カタログによりブランチ全体でガバナンスを継承します。エージェントもブランチを使用して本番に影響を与えずに操作できます。
CI/CDワークフローでは、GitHub ActionsがPRごとにブランチを作成し、マイグレーションを実行してテストスイートを動作させます。スキーマ差分はPRコメントとして自動投稿され、DBAやチームがレビューできます。マージ後はブランチが自動削除されます。開発者はデータベース管理を意識する必要がなく、完全に自動化されたプロセスが実現します。
パート1では開発者Jenの1日を紹介しましたが、本パートでは彼女の新しいワークルールに焦点を当てています。DBAの役割はゲートキーパーから協力パートナーへと変わり、レビューの焦点は「データベースを壊さないか」から「設計は最適か」へとシフトします。パート2ではさらにDBAの新たな責任（ポリシー管理、チームレベルのガバナンス）について詳述し、これらはパート3でさらに議論されます。要約すると、Lakebaseの分岐技術は古い制約を取り除くだけでなく、新しい開発プラクティスとチームコラボレーションモデルを生み出します。