Instantly create isolated PostgreSQL database copies — full data, zero storage overhead, available in seconds. Give every developer, every PR, and every test run its own database.
Database branching is the ability to create a fully isolated copy of a database — including all its data — instantly, without duplicating storage. It works exactly like git branch: you branch from the current state, make changes freely without affecting the source, and delete or merge the branch when done.
The technology behind it is copy-on-write (CoW) storage. When you branch a database, no data is copied. The branch and the source share the same underlying storage blocks. Only when either side modifies a block does a separate copy get written. A branch of a 500 GB database might use only a few MB of additional disk space if very little data is written to it.
This is fundamentally different from pg_dump / pg_restore, which serializes data to disk and reimports it — a process that can take hours for large databases and consumes full storage for each copy.
Every use case that was previously painful with shared databases or slow clones
Every developer gets their own database copy. No more stepping on each other's data or waiting for a shared dev DB to be available.
Spin up a database branch for every pull request automatically. Reviewers and QA test against real data without touching staging.
Apply your ALTER TABLE or data migration to a production clone first. Catch issues — including performance regressions — before they hit prod.
Benchmark queries against a real copy of production data. No synthetic data, no guesswork about whether your indexes will hold.
Replace your stale, hand-managed staging database with a daily or on-demand clone of production. Staging is always current.
When something breaks in production, branch from the exact production snapshot, reproduce the issue, validate the fix, and merge with confidence.
How Vela copy-on-write branching compares to pg_dump and schema-only copies
| Feature | pg_dump / restore | Schema-only copy | Vela Branching |
|---|---|---|---|
| Setup time | 10–60 min (depends on DB size) | < 1 min (no data) | < 30 seconds (full data) |
| Data accuracy | Full — but stale by time of export | Schema only — no production data | Full production data, current snapshot |
| Storage cost | Full copy of data on disk | Minimal | Near-zero (copy-on-write — shared blocks) |
| Isolation | Full — separate DB | Full schema — no data isolation | Full — writes don't affect source |
| Scriptable in CI | Yes, but slow and fragile | Yes, fast | Yes, instant via API |
| Multiple simultaneous copies | Expensive (N × storage) | Cheap | Cheap (shared unchanged blocks) |
| Suitable for load testing | Yes (if export is recent) | No | Yes |
Using database branching in CI/CD? See also: Vela for CI/CD testing
Database branching is the ability to create an isolated copy of a database — including its full data — instantly, without duplicating the underlying storage. The concept mirrors Git branching: you branch from the current state, make changes in the branch without affecting the source, and discard or promote the branch when done. It relies on copy-on-write (CoW) storage: unchanged data blocks are shared between the source and the branch; only modified blocks are written separately.
pg_dump exports a database to a file, then pg_restore imports it — a process that can take minutes to hours for large databases, requires significant I/O, and produces a full second copy of all data on disk. Database branching using copy-on-write storage creates a branch in seconds regardless of database size, with near-zero additional storage cost because unchanged blocks are shared. The branch is immediately readable and writable, not a file that must be re-imported.
Copy-on-write is a storage technique where a clone initially shares all data blocks with the original. When either the original or the clone modifies a block, only the modified block is written separately — the rest remain shared. This makes cloning near-instantaneous and storage-efficient: a 100 GB database branch might use only a few MB of additional disk space if minimal data has been modified.
Yes. Vela exposes branching via API, so CI pipelines (GitHub Actions, GitLab CI, CircleCI, etc.) can create a database branch at the start of a job and delete it at the end. Each PR or pipeline run gets a fully isolated database with real production-like data. See the branch-per-PR workflow guide for a concrete GitHub Actions example.
Yes — this is one of the key advantages of storage-level CoW branching over approaches like Neon's page-server branching. Because branching happens at the storage layer, a 500 GB database creates a branch in the same time as a 5 GB database. The branch is instantly usable with no data transfer.
Spin up a Postgres database, branch it, and see copy-on-write cloning in action — no infrastructure to provision.