In development

MySQL / PostgreSQL · ZFS · Apache-2.0

本番規模のデータベースを、数秒でブランチに。

DB Branch は、ZFS のコピーオンライト（CoW）スナップショットからデータベースのブランチを作ります。データをコピーしないため、ベースがどれだけ大きくても、ブランチは数秒で使い始められます。プルリクエストごと、開発者ごとに専用の DB を用意できます。

GitHub でフォロードキュメント

コア機能は Apache-2.0 ライセンスのオープンソースとして公開する予定です。パッケージはまだ公開していません。

0.5sPostgreSQL

3sMySQL

0Bコピーするデータ

ブランチの作成時間は、3 ノードの試験用クラスターでの計測値です（API を呼んでから接続できるようになるまで）。CoW のため、ベースが大きくなっても作成時間はほとんど変わりません。

上段が本番の生データ、中段がマスク済みのベース、下段がそこから作ったブランチです。

仕組み

ベースさえあれば、ブランチは数秒で作れます

ブランチは、ベースのスナップショットを ZFS でクローンしたものです。クローンはコピーオンライト（CoW）なので、作成時にデータはコピーされず、ブランチが書き込んだブロックの分だけ容量が増えます。

Step 1

ダンプや本番 DB からベースを作る

SQL ダンプを読み込むか、本番 DB やレプリカから定期的にデータを取り込みます。ベースは、ブランチの元になる読み取り専用のデータベースです。

Step 2

スナップショットで時点を残す

データを取り込むたびにスナップショットを作成します。過去のスナップショットからもブランチを作れます。

Step 3

開発者ごと、PR ごとにブランチを作る

ブランチは独立したデータベースサーバーとして動きます。ブランチ上で何を変更しても元のベースには影響せず、リセットや削除も数秒で終わります。

# 各ノードにインストールし、ZFS プールを指定する
$ sudo apt install db-branch
$ sudo db-branch init --pool tank

# ダンプからベースを作り、ブランチを作成する
$ db-branch base create prod --runtime postgres@18.6 --dump /srv/prod.sql.gz
$ db-branch branch create feature-x --base prod --ttl 72h

パッケージはまだ公開していません。以下は公開後の手順の例です。

接続

ブランチへの接続

各ノードで ProxySQL 3.x（無料の db-branch-proxysql モジュール）が動いているため、どのノードに接続してもクラスター内のすべてのブランチにアクセスできます。ポートは MySQL が 6033、PostgreSQL が 6133 です。

直接接続する

ブランチのサーバーにホスト・ポート・ユーザーを指定して接続します。パスワード付きの接続 URL は db-branch branch dsn で確認できます。

ユーザー名で切り替える

ブランチごとに専用のユーザーが作られます。アプリ側は接続文字列のユーザー名を変えるだけで済みます。

クエリのコメントで切り替える

クエリに /*db_branch='name'*/ を付けると、そのブランチに振り分けます。ミドルウェアで HTTP ヘッダーから付与すれば、リクエストごとにブランチを切り替えられます。コメントの指定はユーザー名より優先され、トランザクションの途中でブランチが切り替わることはありません。

# ホストは同じまま、ユーザー名でブランチを切り替える
mysql://feature-x:<password>@node1:6033/app
mysql://pr-1287:<password>@node1:6033/app

-- クエリのコメントでブランチを指定する
SELECT * FROM users WHERE id = 1 /*db_branch='feature-x'*/;

mysql CLI でコメントを使うときは、-c オプションを付けて起動してください。付けないとコメントが削除されます。

機能

チーム開発に必要な機能をひととおり備えています

Engines

MySQL と PostgreSQL に対応

ベースごとにランタイムのバージョンを選べます。ブランチはベースと同じバージョンのサーバーで動きます。

Scheduled refresh

本番データを自動で取り込む

接続先と間隔を設定すると、ダンプ、読み込み、スナップショットの作成までを自動で行います。ダンプファイルは読み込み後すぐに削除します。

Cluster

3 ノード以上で冗長構成

Raft でクラスターの状態を共有するため、どのノードからでも操作できます。スナップショットはノード間で複製されます。

Interfaces

コンソール、CLI、API

Web コンソールで一覧の確認や操作ができます。CI からは CLI や REST API で、PR ごとにブランチを作成・削除できます。

AI agents

MCP で AI エージェントにも

Claude Code などのエージェントが自分用のブランチを作り、本番に触れずに SQL を試せます。

Storage

lz4 で圧縮して保存

ベースもブランチも ZFS の lz4 圧縮で保存します。ブランチは CoW のクローンなので、1 つのベースから 10 個作っても、書き込みが少ないうちはベースとほぼ同じ容量で済みます。

Reset

数秒で作成直後の状態に戻す

作成直後の状態を CoW のスナップショットとして保持しています。リセットはそこへのロールバックなので、SQL を再実行せずに数秒で終わります。

Masking

無料のマスキングツールを同梱

PostgreSQL は Greenmask か PostgreSQL Anonymizer、MySQL は Greenmask（ベータ版）で、マスク済みのベースを作れます。

Operations

有効期限、通知、バックアップ

ブランチに有効期限を設定すると、期限が来たときに自動で削除されます。Slack や Webhook への通知と、クラスター状態のバックアップにも対応しています。

本番データの扱い

開発者に渡すのはマスク済みのデータだけ

Business プラン（予定）では、本番データの取り込みからマスク、検査、配布までを一連の流れで実行できます。ルールを変更するには、変更した人とは別の人の承認が必要です。

取り込み

本番 DB やレプリカから定期的にデータを取り込みます。

隔離

生データのベースは管理者しか扱えず、ブランチも作れません。

マスク

更新のたびに、承認済みのルールで自動的にマスクします。

検査

設定した検査で 1 行でも見つかれば、そのマスク結果は破棄します。

配布

検査を通ったスナップショットからのみ、ブランチを作れます。

何をどうマスクするか、その結果で十分かどうかは、お客様に判断していただくものです。DB Branch はその判断どおりに処理を実行して記録を残しますが、マスクの結果そのものを保証するものではありません。

動作環境

正式な最小要件はまだ決めていないため、下の表は試験に使っている構成です。

OS	apt でパッケージを入れられる Linux（Ubuntu 24.04 LTS で試験）
ストレージ	ベースとブランチを置く ZFS プール（OpenZFS 2.2 で試験）。データは lz4 で圧縮されます。
データベース	MySQL 8.0 / 8.4、PostgreSQL 18 で試験しています。
ノード数	1 台から動作します。3 台以上でクラスターを組むと、1 台が停止しても使い続けられます。
CPU とメモリ	試験用クラスターは 6 vCPU・11 GB が 1 台、2 vCPU・3 GB が 2 台です。
ブランチのメモリ	各ブランチのサーバーに、既定で 128 MB のキャッシュ（InnoDB バッファプールまたは shared_buffers）を割り当てます。設定で変更できます。
ディスク	lz4 で圧縮したベースのデータと、各ブランチが書き込んだ分を使います。変更のないブロックは CoW で共有されます。