Copy-on-Write ストレージ

データベース全体を数秒でクローン

実データを含む完全な PostgreSQL コピーを 30 秒未満で作成できます。dump も restore も不要で、初期追加ストレージもほぼゼロです。

Vela Sandbox を無料で試す ブランチングを見る

従来のデータベースクローンがつらい理由

標準的な方法は今でも pg_dump と pg_restore です。小規模 DB なら問題ありませんが、本番規模になるとチームの速度を大きく落とします。

100 GB データベースにおける典型的な pg_dump / pg_restore

  • → Dump に 30〜60 分かかり、大きなアーカイブを生成します。
  • → Restore にさらに 30〜60 分かかり、フルサイズの追加ディスクが必要です。
  • → 10 個の並列コピーでおよそ 1 TB の追加ストレージになることがあります。
  • → クローンが遅すぎるため、共有 staging に戻ってしまうチームが多いです。

クラウドのスナップショット復元は改善ですが、利用可能になるまで数分かかり、やはりフルコピーを作ります。

Copy-on-Write クローンの仕組み

Vela はストレージ層でクローンを作成します。ソースとクローンは最初に同じブロックを共有するため、大量コピーが発生しません。

書き込みが発生したブロックだけが別保存されます。そのため作成は高速で、ストレージ増加も実際の変更量に比例します。

  • データベースサイズが大きくなっても作成時間はほぼ一定です。
  • 読み取り専用クローンは追加ストレージをほとんど使いません。
  • 書き込みは完全に分離され、ソースへ影響しません。
  • クローン削除は即時です。

高速クローンでできること

クローンが速く安く使い捨て可能になることで現実的になるワークフローです。

マイグレーション前テスト

本番クローン上で先にスキーマ変更を検証してから本番へ適用します。

  • 実データで ALTER TABLE を検証
  • 制約エラーを早期発見
  • 移行後の性能を測定

負荷試験と性能試験

合成データではなく、本番規模データでベンチマークします。

  • 実際の分布とカーディナリティを維持
  • 安全に EXPLAIN ANALYZE を実行
  • テスト後はクローンを破棄

開発環境

共有 dev DB ではなく、各エンジニアに完全なコピーを配布します。

  • 本番に近いローカル環境
  • 書き込み競合なし
  • 作成も削除も高速

データマスキングパイプライン

本番をクローンし、クローン内でマスキングを行って安全なコピーだけ共有します。

  • 本番完全データから開始
  • クローン内で PII をマスク
  • 元データベースは常に保護

クローン方式の比較

項目 pg_dump / restore クラウド snapshot restore Vela CoW クローン
作成時間（100 GB） 45〜90 分 10〜30 分 < 30 秒
クローンごとの追加ストレージ 100 GB フルコピー 100 GB フルコピー 作成時ほぼゼロ
10 個の同時クローン ~1 TB 追加 ~1 TB 追加 データ変更まではほぼゼロ
API 自動化 CLI のみ クラウド API REST API と UI

関連ページ

データベースブランチの概要 Postgres staging 環境 Vela への移行

よくある質問

なぜ Vela は PostgreSQL をこんなに速くクローンできるのですか？

Vela はストレージ層で copy-on-write を使います。変更されていないブロックはソースと共有されるため、作成時に完全転送が不要です。

クローンとブランチの違いは何ですか？

クローンは分離されたコピーです。ブランチは同じ仕組みを使いますが、ブランチングのワークフローとして管理されます。

クローンはどれくらいストレージを使いますか？

作成時はほぼゼロです。クローンまたはソースが別々のブロックを書き換えたときにだけ追加ストレージが増えます。

稼働中の本番 DB をクローンできますか？

はい。Vela は本番トラフィックを止めずに一貫したスナップショットを作成します。

数秒でデータベースをクローン

インフラを準備せずに sandbox で copy-on-write cloning を試せます。

Vela Sandbox を無料で試す PR ごとのブランチ