進化するデータベース開発を有効にする：Lakebaseによるデータベースブランチング

このシリーズが存在する理由

Evolutionary Database Design で説明され、Refactoring Databases: Evolutionary Database Design で具体化された方法論は、20年間明確でした。7つのプラクティス、70以上の名前付きリファクタリングのカタログ、移行メカニズム – これらすべてが文書化され、査読され、教えられてきました。

その方法論は、2010年に Continuous Delivery（第12章：データ管理）でCI/CDに到達しました。マイグレーションはデプロイメントパイプラインのファーストクラスアーティファクトになりました。コードとしてのデータベース変更の規律は、より広範なCI/CD運動に到達しました。CDが解決しなかったのは、パイプラインごとの分離でした。パイプラインはマイグレーションを実行できましたが、ターゲットデータベースが必要であり、そのターゲットは共有されていました。プラクティス#4 – 全員が独自のデータベースインスタンスを持つ – は、ほとんどのチームで願望のままでした。なぜなら、真の開発者ごとの本番環境形状のデータベースは、時間、お金、DBAサイクルを消費するからです。ギャップを回避するために登場した補償レイヤー（モックオブジェクト、共有ステージング環境、インメモリデータベースの代替、DBAチケットキュー）は、設計ではなく、デフォルトで基本的な方法論になりました。

2026年、Databricks Lakebaseにコピーオンライトデータベースブランチングが登場します。1テラバイト規模の本番データベースの、作成時のストレージゼロ、1秒でのブランチは、O(1)操作になりました。プラクティス#4を願望のままにしていた制約が解除されました。

このシリーズは、制約が解除されたときに何が変わるかを説明します。方法論が変わるのではなく、それが維持されること、初めて登場するプラクティス、自動になるチーム規模のガバナンス、DBAの役割進化、そしてエージェントが人間の対パートナーと共有する新しい基盤です。

Jenに会う

Jenは、Evolutionary Database Design の開発者キャラクターです。そのエッセイでは、彼女はデータベースリファクタリングを実装しました – inventory_code フィールドを location_code、 batch_number、および serial_number に分割すること – 定期的なユーザーストーリーとして、DBAと開発者が協力できること、スキーマが小刻みに進化できること、そしてマイグレーションが変更を安全に前進させることを示しています。

このシリーズは、Jenが20年後にどうなっているかから始まります。彼女が従う方法論は、2003年に彼女が従ったものと同じです。新しいのは、彼女のワークフローの下にある基盤です。コピーオンライトデータベースブランチングにより、彼女が読んできたプラクティスが本番規模で運用上現実のものとなります。このシリーズの3つのパートを通して、彼女は3つのスコープで同じJenです – 彼女の1日（パート1）、彼女の新しいプレイブック（パート2）、そして彼女のチーム（パート3）。

パート1：Jenのストーリー：1つの機能、1つのデータベース変更

これがどのように機能するかを理解するために、Jenという開発者が、ユーザーが在庫品の位置、バッチ、シリアル番号を表示、検索、更新できるようにするというタスクをどのように実装するかを、その旅をたどってみましょう。

以下は、Jenがこのタスクを達成するために取るさまざまなステップを説明しており、そのステップを説明しながら、Jenのワークフローが従来のデータベースを使用する場合と、データベースブランチングを最小限のコストで可能にするLakebaseを使用する場合でどのように変化するかを比較しようとします。

Jenが機能タスクに取り掛かる

Jenは、単純に見える機能を引き受けます。製品チームは、ユーザーが在庫追加中にアイテムの位置、バッチ、シリアル番号をキャプチャし、後でアプリケーションフローで使用できるようにしたいと考えています。外部からは、変更は小さく感じられます。画面にフィールドを追加し、値を保存し、アイテムの在庫画面に表示し、後でダウンストリームの決定で使用するかもしれません。

Jenにとって、アプリケーションの変更は想像しやすいです。彼女はフォームがどこにあるかを知っています。彼女はリクエストを処理するサービスを知っています。彼女はより多くの属性を必要とするモデルオブジェクトを見ることができます。しかし、変更を最後まで追跡した瞬間、彼女は実際の依存関係、つまりデータベースも変更する必要があることに気づきます。

いくつかの新しい列が必要であり、本番環境の既存のデータは保持され、意味的に正しい必要があります。アプリケーションは、古いデータと新しいデータを安全に処理する必要があり、新しいフィールドが正しく保存、読み取り、表示されることを証明するテストを追加する必要があります。単純な機能に見えたものは、調整されたアプリケーションとデータベースの変更になり、既存の本番スキーマとデータを新しいスキーマに移行する責任が追加されました。

共有データベース

Jenは、これから着手する作業のためにコードブランチを作成し、共有データベースを使用しており、チームの他のメンバーも開発のために同じデータベースを使用しているため、共有データベースの他のユーザーに影響を与える可能性のあるデータベースレイヤーへの変更についてすぐに考え始め、他のユーザーのために安全にする方法を計画し始めます。ローカルでアプリケーション変更を実行し、単体テストと統合テストを実行できるでしょうか？各オプションにはコストがかかります。彼女は待つことができます。彼女はチームに調整を依頼できます。彼女はDockerでローカルPostgresを起動し、1週間前の pg_dump でシードし、違いが問題にならないことを願うことができます。彼女はコンテナでローカルデータベースを実行するか、H2またはSQLiteのインメモリデータベースにフォールバックできます。これは高速に実行されますが、ダイアレクトが間違っているため、ローカルではテストがパスし、実際のPostgresで未知のエラーが発生します。スキーマとデータ移行スクリプトをテストすることさえできるでしょうか？他の人を壊すことへのこの恐れは彼女を遅くし、同時に複数のオプションを試すことを可能にしません。

共有データベースでは、一人の開発者がビジネスロジックの変更をテストしている可能性があり、別の開発者がデータ移行をデバッグしている可能性があり、さらに別の開発者がJenが理解していないテストデータを作成している可能性があります。Jenがスキーマ変更を共有データベースに適用すると、他の誰かの作業を壊してしまう可能性があります。彼女がテスト中に他の誰かがスキーマを変更すると、彼女の結果はもはや信頼できない可能性があります。彼女がテストデータを追加すると、他の開発者の仮定に干渉する可能性があります。

Jenは、共有データベースが空くのを待つことができます。これはチームを衝突から保護しますが、小さな機能をスケジューリングの問題と生産性の損失に変えます。彼女は他の開発者と手動で調整できます。「今開発を使っていますか？」「マイグレーションを実行できますか？」「次の1時間はデータをリセットしないでください。」リレーレースのバトンのようなものです。それはしばらくの間機能しますが、特にリモートまたは複数のタイムゾーンのチームでは、スケーリングしません。

Jenは別のオプションを考えます。ローカルインメモリデータベースを使用することです。このセットアップは、チームの他のメンバーが使用しているデータベースの状態と一致しないことを彼女は知っています。つまり、彼女のソリューションに自信を持てません。変更はローカルでは機能するかもしれませんが、ステージングや本番などの上位環境の実際のデータやスキーマに遭遇すると、後で失敗する可能性があります。

Jenが直面している本当の問題は、*フィードバックが遅い*ということです。彼女は変更を加えることができますが、変更が機能したかどうかを知ることはできません。しかし、高速で現実的なフィードバックがなければ、データベースの変更はチームが慎重に扱うものになり、最初に機能したソリューションを選び、決して実験したり複数のソリューションを試したりすることはありません。その結果、最適ではないソリューション、生産性の低下、そして開発者の不満につながります。

個別のデータベースブランチ

Lakebaseを使用することで、Jenは個人の使用のためにデータベースをブランチする能力を持ち、この機能は彼女の働き方を完全に変えます。

共有開発データベースが利用可能になるのを待つ代わりに、Jenは彼女の機能のためにデータベースブランチを作成するか、databricks postgres create-branchまたはVS Code / Cursor 拡張機能を使用します。これにより、作業の形状がすぐに変わります。彼女はもはやチームに静かな時間枠を求めていません。彼女はもはや、誰がどのマイグレーションを実行できるか、いつ実行できるかについて他の開発者と交渉していません。彼女はもはや、半完成した変更を他のすべての半完成した変更から保護しようとしていません。彼女は、アプリケーションが最終的に本番環境で使用するのと同じ種類のデータベース環境から作成された、独自の分離されたデータベーススペースを持っています。

このブランチにより、Jenは作業対象のデータベースの状態の高速コピーを取得できます。彼女は今、アプリケーションが本番環境を直接クエリした場合と同じPostgresエンジン、同じスキーマ、同じガバナンスポリシー、そして同じ本番形状のデータを持っています。唯一の違いは、このブランチは変更、破棄、または再作成でき、他のワークロードに影響を与えないことです。彼女は、本番環境とは異なる動作をする単純化されたローカルデータベースに対してテストしているわけではありません。彼女は、チームが本番環境で使用しているのと同じデータベースタイプで、データベースの変更を成功または失敗させるスキーマルール、制約、インデックス、参照データ、およびマイグレーション履歴と同じ種類のものを扱っています。これらの問題の多くは、分離された単体テストでは現れないため、そのリアリズムは重要です。それらは、新しいマイグレーションが既存の構造、既存のデータ、既存の仮定、および既存のアプリケーションの動作と衝突したときに現れます。

これで、Jenはデータベースの変更を設計の一部として扱うことができ、単なるデプロイメントステップとしてではなくなります。彼女はまず明白なバージョンを試すことができます。新しい列を追加し、既存の列を分割するためのデフォルトロジックを設定し、データベースマイグレーションスクリプトを作成し、アプリケーションを更新し、テストを実行します。その後、より良い質問をすることができます。このマイグレーションスクリプトは本番データの量に対して機能するか、本番環境のデータ品質は彼女のスクリプトが期待するものか？データマイグレーションスクリプトは、ビジネス情報の欠落を隠していないか？設定は単純な列、ルックアップテーブル、または後で情報が増える可能性があるので別のitem_informationテーブルとしてモデル化されるべきか？クエリパターンにはインデックスが必要か？この設計は、下流のレポート作成を容易にするか、それとも難しくするか？古いワークフローでは、データベースの変更は高価であるため、これらの質問はしばしば圧縮されていました。

ブランチ化されたワークフローでは、Jenは機能がまだ形成されている間にそれらを探索できます。DBAは彼女とペアになり、本番環境のニュアンスとデータ量について彼女をガイドできるため、事後レビューアではなく、ソリューションの設計に貴重なインプットを提供できます。

アプリケーションとデータベースの変更を同時に行う

Jenはマイグレーションスクリプトを作成します。彼女のチームがFlyway、Liquibase、Alembic、Knex、Prismaのいずれを使用しても、スクリプトはアプリケーションの変更とともにコードリポジトリに格納されます。スキーマとデータのマイグレーションはコードと共に移動します。

（これはSplit Column リファクタリングです。これは、7つのプラクティスを運用化した書籍Refactoring Databasesにカタログ化されている約70のパターンの1つです。）

彼女は、flyway migrateを使用してブランチにマイグレーションを適用します。このツールは、実際の形状のデータに対して1秒未満で実行されます。彼女はリポジトリコードを更新して、3つの新しい列を読み書きします。彼女はテストスイートを実行します。テストは、モックやインメモリの代替なしで、実際のPostgresに対してパスします。

クリーンな状態にして別の方法を試したい場合は、ブランチを破棄し、本番環境から新しいブランチを作成します。さらに1秒。クリーンアップチケットはありません。DBAは関与しません。

同じJen。同じリファクタリング。変わったのは機能です。

より速く失敗するためのスペース

実験できる能力は重要です。進化的な設計と開発は、定義済みのチェックリストを迅速に進むことだけではありません。それは、作業がより具体的になるにつれて学習することでもあります。Jenは、最初のスキーマ設計が機能するものの、厄介なアプリケーションロジックを生み出す可能性があることを発見するかもしれません。2番目の設計はよりクリーンですが、既存のレコードのマイグレーションをより複雑にする可能性があることを発見するかもしれません。今行われた小さな正規化の決定が、将来の変更を容易にする可能性があることを発見するかもしれません。彼女が最初に書いたマイグレーションスクリプトでは、SUBSTRINGインデックスが1つずれています。破棄するDROP COLUMNは、新しい列が正しく入力されたことを確認する前に実行されました。彼女自身のブランチがあるので、これらの発見は安価です。彼女はマイグレーションを適用し、アプリケーションを実行し、データを検査し、別のマイグレーションでロールフォワードするか、リセットして別のパスを試すことができます。

このブランチは、作業の感情的な姿勢も変えます。Jenは、共有開発データベースが他の誰かに依存している可能性があるため、過度に注意する必要はありません。彼女はチームにすべての実験を通知する必要はありません。他の開発者がそれに躓く可能性があるため、テストデータをすぐにクリーンアップする必要はありません。彼女のブランチは、未完成の思考のための安全な場所です。一時テーブル、失敗したマイグレーションの試み、厄介なテストデータ、および半形成された設計を含めることができ、他の誰にもノイズを作成しません。

同時に、分離はチームの標準からの切り離しを意味するものではありません。Jenは依然としてマイグレーションスクリプトを作成します。彼女は依然としてアプリケーションコードとデータベースの変更を一緒に保ちます。彼女は依然としてテストを実行します。彼女は依然として最終設計がレビューされることを期待しています。違いは、彼女がチームに洗練されたバージョンについて推論を求める前に、作業の厄介な部分をプライベートかつ迅速に行うことができることです。プルリクエストを開く頃には、会話は、安全なテスト場所があったかどうかではなく、設計が正しいかどうかを中心にすることができます。

これが重要なシフトです。データベースブランチは、Jenに高速で現実的で分離されたフィードバックを提供し、それを技術リーダーやDBAにレビューしてもらうこともできます。彼女のデータベースブランチを見せることで。高速とは、彼女が必要なときに環境を作成できることを意味します。誰かが彼女のためにプロビジョニングしてくれるのを待つのではなく。現実的とは、本番環境で重要なデータベースの動作と同じ種類のものをテストしていることを意味します。分離されているとは、彼女の実験が他の誰の邪魔もしないことを意味します。これら3つのプロパティが組み合わさることで、データベースの変更はボトルネックから機能開発の通常の μέροςへと変わります。

Jenは今、アプリケーションとデータベースを一緒に進めることができます。彼女のコードブランチとデータベースブランチは、同じタスクの2つの側面になります。一方はアプリケーションの変更を保持します。もう一方は、それらの変更が実際に動作するデータベースを提供します。Jenは、待機、調整、または単純化されたセットアップでごまかす代わりに、設計、テスト、改訂、学習を行うことができます。機能はまだ小さいですが、もはやデータベースがそれを遅くする原因ではありません。

プルリクエストを開く

Jenはアプリケーションコードとマイグレーションスクリプトの両方をコミットします。彼女はPRを開きます。

CIはJenがちょうど行ったことと同じことを、チームのために行います。それは独自のテンポラリLakebaseブランチを作成し、マイグレーションを適用し、アプリケーションテストスイートを実行し、移行されたスキーマに対してデータベーステストを実行し、マイグレーション自体を検証し（きれいに適用可能、冪等、元に戻せる）、PRにschema-diffコメントを投稿して、どのデータベースオブジェクトが変更されたかを正確に示します。

レビュー担当者は、コードがそれを使用しているコードとインラインでスキーマ変更が何をするかを見ることができるようになり、コンテキストの理解を抽象的なものから具体的なものへと変えます。

Screenshot of the Branch Diff Summary view from the Lakebase SCM Extension

変更のレビュー

以前のワークフローでは、データベースレビューの質問は「これがデータベースを壊すか？」でした。これは、すべての変更が本番スケールの結果をもたらす可能性があるため、個別に確認する必要があったDBAによって管理されていました。レビューは同期的に行われ、スケジュールが衝突し、DBAのカレンダーはキューとなり、時には「市場投入までの時間」のためにDBAが見過ごされることもありました。

新しいワークフローでは、質問は「これは正しい設計か？」です。DBAはすでにCIによって投稿されたスキーマ差分を確認済みです。彼らはすでに、実際のデータブランチでマイグレーションが正常に実行されたことを確認済みです。JenはDBAを議論に呼び出し、彼女が考えていることや試した他のすべてのオプションを示すこともできます。DBAはJenのスケジュールではなく、自身のスケジュールでレビューできます。彼らは、以前はすべての時間を費やしていた保護的なゲートキーピングではなく、ソリューション開発サイクルのもっと早い段階でレビューを提供し、データ整合性、インデックス戦略、将来の拡張性、または長期的な保守性に関するソリューションを改善できます。

チームはコードとデータベースを一緒にレビューします。1つのPR。1つの会話。同じウィンドウで。

自信を持ってマージする

マイグレーションはすでに実際のデータブランチに対してテスト済みです。アプリケーションはすでに変更されたスキーマに対して実行済みです。スキーママイグレーションはレビュー済みです。CIビルドはまったく同じ手順を実行し、1時間グリーンでした。

Jenがマージすると、マイグレーションは次の環境に適用され、CI環境とJenのデータベースとコードのブランチはクリーンアップされます。これにより、データベースの変更がリリース夜のサプライズではなくなります。

Jenが vừa thực hiện là thực hành thứ năm từ bài luận năm 2003: tích hợp liên tục các thay đổi cơ sở dữ liệu.

Jenの旅が示すこと

データベースの変更は通常の開発の一部になります。ブランチングは、待機時間、リスク、および調整オーバーヘッドを削減します。Jenの毎日のループは、データベースレイヤーで高速で独立したフィードバックを提供します。

パート2 – Jenの新しいプレイブックでは、何が持ち上げられ、なぜJenがキャリア全体で取り組んできた補償レイヤーが削除できるのかを説明します。コピーオンライトブランチング、それを機能させるアーキテクチャ、そしてそれに続く方法論の最適化です。

パート3 – Jenのチームのスケーリングでは、Jenが50人の開発者の1人である場合、またはホワイトラベル製品に取り組んでいる場合、または多くのドメインが含まれるモジュラーモノリスに取り組んでいる場合、Jenのストーリーがどのようになるかを見ていきます。ブランチ作成時のガバナンス、DBAのリフレーム、エージェントインザループ、そしてDBAのカレンダーがチケットキューではなくなったときに開かれるプラットフォーム設計作業です。

この投稿でJenが使用したIDEツールのツアーを希望する読者向けに、コンパニオン：プラグインウォークスルーがあります。これは、VS Code / Cursor用のLakebase SCM拡張機能です。

最後に、エージェントが使用するためのLakebase App Dev Kitと、人間がフォローするための電子書籍がまもなくリリースされます。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事