Managed Postgres では、ポイントインタイム リカバリ (PITR) を使用して、独立したデータベースブランチを作成できます。
ブランチは、既存のデータベースの特定時点から作成される、完全に独立した PostgreSQL デプロイメントです。ブランチは、ソースデータベースに影響を与えることなく、開発、ステージング、テスト、デバッグ、データ検証、または復旧のワークフローに利用できます。
プライマリデータベースとストレージを共有するコピーオンライト実装とは異なり、Managed Postgres のブランチはバックアップから復元され、独立した PostgreSQL デプロイメントとして動作します。
ブランチの作成には、ポイントインタイム リカバリ (PITR) で使用されるものと同じバックアップおよび復旧インフラストラクチャが使われます。
ブランチを作成すると、Managed Postgres はオブジェクトストレージからベースバックアップを復元し、要求された復旧時点に到達するために必要な WAL セグメントを再生したうえで、復旧した状態から新しい PostgreSQL デプロイメントをプロビジョニングします。復旧が完了すると、ブランチはソースデータベースから独立して動作します。
作成されるブランチは、選択した時点におけるソースデータベースの完全なコピーです。
本番環境またはステージング環境のデータベースからブランチを作成し、アプリケーションの変更、移行、新機能を実際のデータに近い環境で検証します。
本番ワークロードに影響を与えずに、本番環境にできるだけ近いステージング環境を維持します。
スキーマ変更、索引戦略、クエリ最適化は、本番環境にデプロイする前に事前にテストしてください。
トラブルシューティング、監査、またはアプリケーションの動作確認のために、データベースを特定の時点に復旧します。
ブランチは独立した PostgreSQL のデプロイメントであり、ソースデータベースとは別にサイジングできます。
たとえば、本番デプロイメントはより大きな構成で実行し、開発用またはステージング用のブランチはコストを抑えるためにより小さなコンピュートプロファイルを使用できます。これにより、チームは本番環境と同等のコンピュートリソースを用意しなくても、一時的な環境を作成できます。
Managed Postgres では NVMe ベースの PostgreSQL ストレージを使用しているため、ブランチはストレージレベルのコピーオンライト機構によって作成されるのではなく、バックアップから復元されます。そのため、ブランチの作成は瞬時には完了しません。
通常、ブランチの作成時間は次の要因に応じて数分から数十分程度かかります。
- データベースサイズ
- バックアップサイズ
- 復旧ポイント
- 再生する必要がある WAL の量
- クラスター全体の構成
ほとんどの導入環境では、ブランチは数分以内に利用可能になります。データベースの規模が大きい場合は、さらに時間がかかることがあります。
ブランチの作成時間がワークフローのボトルネックになっている場合は、ClickHouseチームにお問い合わせください。多くの場合、ブランチの復旧性能は、ワークロードの特性や復旧要件に応じて最適化できます。
よくある質問のひとつに、すべての開発者が開発環境として本番ブランチを使うべきか、というものがあります。
ブランチはテスト、検証、ステージングのワークフローには有用ですが、日常的なアプリケーション開発には、一般的に推奨される方法ではありません。各ブランチは独立した PostgreSQL デプロイメントであり、backups から復元したうえで、それぞれを個別に維持管理する必要があります。大量のブランチを作成すると、インフラストラクチャのコストや運用の複雑さが増す可能性があります。
ほとんどの組織では、次のことを推奨しています。
- ステージング、テスト、デバッグ、検証のワークフローには PostgreSQL ブランチを使用する。
- 日常的な開発にはローカルの PostgreSQL 環境を使用する。
- 必要に応じて、合成の開発用データセットを生成するか、サニタイズ済みのデータセットを使用する。
- 本番由来のブランチに対して日常的な開発を直接行うことは避ける。
このアプローチにより、本番システムへの負荷を減らし、開発速度を向上させるとともに、本番データが適切に保護された状態を維持しやすくなります。
Docker を使用してローカルの PostgreSQL 開発環境を作成する方法については、ローカル開発環境を参照してください。
一般的な手順は次のとおりです。
ブランチは、データベースの本番環境に近いコピーが必要な環境に最適です。通常の開発では、ローカルのPostgreSQL環境のほうが、一般に、より高速で低コストかつスケーラブルなワークフローを実現できます。 Last modified on July 3, 2026
