「database branching」にはブランディングの問題があります。
長いあいだ、これはだいたい次のどれかを意味していました。
dump/restore の長距離走。終わるのは次のスタンドアップか、宇宙の熱的死か、そのどちらかです。
schema-per-branch の幻想。みんな「分離されている」と礼儀正しく言い張る一方で、ロック競合と拡張機能の衝突が大暴れします。
「clone」機能。実態は「本番をコピーしました。請求額の話はしないでください」です。
だからこそ、database branching は死んだと言えます。少なくとも、開発者が人生を嫌い、プラットフォームチームが開発者を嫌うようなあの形は終わりました。
ただし、アイデアそのものは今まで以上に生きています。昇格しただけです。次にあなたのデータベースを扱うのは人間ではありません。インシデントを調査し、マイグレーションを検証し、スキーマ変更を提案し、インデックスを調整し、性能実験を行い、そして 5 分後にもう一度それをやっていいか丁寧に確認するエージェントです。
未来はエージェント、CI、プレビュー環境、QA 自動化、分析用サンドボックス、高速な反復です。データベースは必要なときに次々と作られ、プラットフォームチームに許可を請う必要はありません。
もしそのループをあなたの基盤が支えられないなら、「agentic workflows」があるとは言えません。見た目の良いチャットボットがチケットを切っているだけです。チケットは control plane ではありません。
この世界に必要なのは branching です。ただし、嘘ではない branching です。
そこに登場するのが Vela です。メッセージはとても明快です。同じ Postgres、まったく違う体験。そして何より、違う branching です。
問題は PostgreSQL ではない。その周辺ワークフローだ。
PostgreSQL はこの物語の主役です。実戦で鍛えられ、拡張性が高く、本番で証明されていて、しかも良い意味で退屈です。
退屈ではないのは、Postgres のまわりの当たり前の作業がいまだにどれほど苦痛かという点です。
機能開発用にきれいなデータベースが欲しい？ チケット。
現実的なテストデータが欲しい？ 調整、承認、dump ファイルとプライドを使う三段階の儀式。
安全にマイグレーションを試したい？ 誰も触りたがらない共有 staging を確保する交渉にどうぞ。
データベースエンジン自体は問題ではありません。問題なのは、その周辺にある人間向け、そしてこれからはエージェント向けの体験です。
誤解しないでください。私は Docker を知っていますし、開発やユニットテストでも普通に使います。でも、毎回ゼロから立ち上げて seed データを流し込み、その seed が本番の厄介なエッジケースをほとんど再現していることを祈るのは、良い体験ではありません。
今の「branching」はたいてい「分離のふり」だ
多くの database branching ソリューションは同じ罠にはまっています。「branch のように見える」ことを最適化して、「branch のように振る舞う」ことを最適化していません。
私にとって最大の問題は schema-as-branch 方式です。最初は安くて、1 つの PostgreSQL インスタンスに収まるので魅力的に見えます。しかし副作用のリストはかなりひどいです。
同じサーバー上なのでブランチ間でロック競合が起きる。
拡張機能が衝突する。各ブランチが何でも自由に入れられるわけではないからです。
CPU、メモリ、I/O を共有するので noisy neighbor 問題が起きる。「気をつけて使ってください」に依存する分離はセキュリティモデルではありません。ただの祈りです。
そして最悪なのは、本物のクローンではないことです。間違ったスキーマに向けて実行するまでは「安全に」スキーマ変更を試せるだけです。権限制御で多少は緩和できますが、「how do I restrict a user to a specific Postgres schema」を検索してみれば分かります。
これはオープンスペースにパーティションを置いて「個室です」と呼ぶようなものです。実際には隣の席で誰かがツナを食べています。
Vela が違う理由: ブランチは本物のデータベースだ
すべてを変える一文があります。
Vela における branch は本物の PostgreSQL データベースです。 スキーマではありません。疑似 namespace でも、論理コピーでもありません。本物の Postgres インスタンスです。
各 branch は専用の micro virtual machine の中で、完全に分離された Postgres インスタンスとして動作します。リソース制限もテナント境界も「みんなが行儀よく使うこと」を前提にしていません。
これによって、従来の branching を脆くしていた問題の多くが一気になくなります。
- 1 つの branch が他の branch からリソースを奪うことはありません。
- 拡張機能の衝突も起きません。
- 隣の branch とロック崩壊を共有しません。
- 同じプロセスを共有しないので挙動が漏れません。
- 他の branch のデータを誤って壊すこともありません。
利用者の視点では、これは「branching は面白いデモ」から「branching はソフトウェアをテストして出荷する標準手順」への違いです。
Vela は新しいデータベースではない。それが重要だ。
はっきり言います。Vela は新しいデータベースエンジンではありません。
新しいクエリ言語を発明しません。
SQL とあなたの間に独自の抽象化レイヤーを挟みません。
将来のアップグレードで泣くことになるような Postgres fork でもありません。
Vela は upstream Postgres を使います。つまり ORM、マイグレーションツール、ドライバ、BI ツール、スクリプト、そして誰も触れたくない 2017 年製の社内ツールまで、そのまま動き続けます。
これは重要です。branching platform を名乗るものが全面的な replatforming を要求した瞬間、それはもう branching ではありません。転職です。
人にもエージェントにも、コンテキストが王様だ
昔ながらのデータベース運用は、人間が摩擦を我慢する前提でできています。
- 「チケットを切る」
- 「待つ」
- 「調整する」
- 「慎重にやる」
- 「あとで片付ける」
エージェントはそんなものを受け入れません。CI も受け入れません。速いプロダクトサイクルも受け入れません。
多くのチームは production、staging、dev/QA の動物園を抱えています。更新頻度が低く、全員がドリフトを許容しているうちは「回っている」ように見えます。しかしエージェント時代には、このモデルは壁にぶつかります。
安全で、分離されていて、しかも現実的なデータベース環境を素早く作れないワークフローは、そのままボトルネックになります。そして最も高くつくのは compute ではなく、失われる反復速度です。
理由は単純です。staging は放っておくと prod からずれていきます。データ分布は変わり、拡張機能も異なり、性能特性も変質します。人間は経験則と勘で埋め合わせます。エージェントに勘はありません。あるのは入力だけです。
エージェントが古いデータや非現実的なデータでマイグレーションを検証すると、見た目は筋が通っていても本番分布では失敗する結果を返します。これは LLM の問題でも、人間の問題でもありません。コンテキストの問題です。そしてコンテキストの問題は「もっと良いプロンプト」では解決しません。
Vela のモデルは、セルフサービス、本物の分離、高速な branching、そして簡単に捨てられることを中心に設計されています。開発者は共有 staging を壊さずにマイグレーションを試せます。QA は予定調整なしで機能検証ができます。アナリストは本番を延命装置につながずに重いクエリを流せます。そしてエージェントは重要な変更を自動で検証し、提案できます。
そのうえでプラットフォームチームは、本当に欲しかったものを手に入れます。予測可能性、明確なテナント境界、そして全員の実験のためにオンコールを背負わずに「はい」と言えることです。
本当の仕掛けはストレージだ。だから branching は安い。
「branch ごとに本物のデータベース」と聞くと高そうですが、Vela は毎回テラバイトを素直にコピーしているわけではありません。
“Building an Agent-Ready Postgres Data Platform” の中で Rob が説明しているように、この負荷に合うのは shared-everything + copy-on-write (COW) です。この動画では Copy-on-Write の利点と仕組みも説明しています。
考え方はシンプルです。branches はベーススナップショットを共有し、branch 作成はメタデータ操作だけなので高速で、ストレージオーバーヘッドは「本番全体の大きさ」ではなく「その branch がどれだけ変化したか」に比例します。
Vela は simplyblock を 分散ストレージエンジン として使い、storage レイヤーでの copy-on-write を実現しています。
ここで database branching は特別イベントではなく、日常的に使える基盤になります。Git branch を切るのと同じ感覚です。ただし対象はデータベースなので、間違えたときの値段は少し高いですが。
これはエージェントの現実にも合っています。価値の高いエージェント作業の多くは read-heavy です。スキーマ解析、分布サンプリング、制約検証、EXPLAIN 計画の確認、マイグレーションテスト。必要なのは本番級のコンテキストであって、本番データの完全な物理コピーではありません。COW はその非対称性をうまく使えます。
分離は必要だが、それだけでは足りない
エージェントには権限制御の境界も必要です。
agent-ready blueprint はここをはっきり言っています。ロールベースアクセス制御、クォータ、環境レベルのポリシーが必要です。どこで行動できるのか、何を変更できるのかを制限しなければなりません。
「タスクごとに 1 branch」は安全境界になりますが、それでもプラットフォームにはガバナンスが必要です。branch 専用 credentials、branch 単位の permissions、きれいな promote/discard フローは、あってもいい要素ではありません。これが「エージェントは仕事を速くする」と「エージェントはインシデントを速くする」の分かれ目です。
Vela は分離を第一級の前提として扱うため、branching の基本機能も「環境を安心して捨てられること」を軸に設計されています。Vela は permissions、resource limits、VM 境界によって分離を実装しています。
では、database branching は死んだのか？
はい。
古い形は終わりました。スキーマハック、dump/restore の儀式、実は請求額を増やすだけの clone ボタン、「信じてくれ、分離されてるから」という雑なやり方。
しかし、本物で、安全で、高速なデフォルトワークフローとしての database branching は、これから始まるところです。
面白いのは、MCP (Model Context Protocol) の完全な配線や巨大な自律ランタイムがなくても、すでに恩恵を受けられることです。すでに agentic な開発をしていても、まだ自分でコードを書いていても、大規模データセットから即座にクローンされた branch は、私がずっと求めていた変更検証、修正確認、マイグレーションテストの形そのものです。これを大きな規模で本当にやれる機会は、今までありませんでした。今までは。
もし今日から branch-first の習慣を取り入れ、マイグレーション確認も、性能調査も、危険な実験も、信頼できる基準線から複製した新鮮な branch 上で行うなら、将来エージェントを安全に使うための土台をすでに築いていることになります。現実的なコンテキストと厳格な分離は、摩擦なく共存できると証明できるからです。
Vela の賭けは単純です。Postgres は退屈なまま、体験だけが痛くなくなる。
branch-first な Postgres を体感したいなら、Vela Sandbox を試して、本気で branch を切ってみてください。