Copy-on-write
A branch starts from its parent’s data without copying it.
Test every migration before it merges
Every pull request gets its own Postgres branch, copied from production or staging. It is created when the pull request opens and deleted when it closes.
Its own connection string
Each pull request gets an isolated Postgres database.
Deleted on close
The branch goes away when the pull request merges or closes.
The problem
Schema changes are the ones nobody wants to merge blind
Most teams review migrations against a shared staging database that does not look like production.
- One staging database, shared by the whole team
- Access limited to a few people
- Stale data and seed scripts that no longer match production
- Two pull requests that change the schema collide
- A real copy of the data means a dump and restore nobody has time for
A branch copies no data
The branch reads its parent’s data and keeps only what the pull request changes, so it is ready in about three seconds with the full schema and rows.
- 01
Pull request opens
A developer or a coding agent opens a pull request.
- 02
A database branch is created
The Xata GitHub App creates a branch from the root branch you picked, staging if you have one and production otherwise, and comments the branch name on the pull request.
- 03
Review against real data
Run the migration on the branch with xata roll migrate and point the app at it. Reviewers see the change against the real schema and real rows.
- 04
The branch is deleted on close
When the pull request merges or closes, the GitHub App deletes the branch. Nothing is left running.
Under the hood
See the architectureHow copy-on-write branching works
Xata separates Postgres compute from copy-on-write storage.
Set it up
Two ways to set it up
GitHub App or GitHub Actions
- GitHub App
- GitHub Actions
- 01Link the repository to a Xata project once
- 02Every pull request gets a branch, with no API key stored in GitHub
- 03Need custom branch names, seed data or a merge check? Use the Actions workflows
Let your coding agent do it
- Claude Code
- Cursor
- Codex
- 01The agent creates the branch and runs the migration against it
- 02It checks the result
- 03It opens the pull request, with a working database behind it
Under the hood
Coding agents
Your agent can run the whole workflow
Connect the Xata MCP server or install the CLI, and your coding agent can create branches, apply migrations and read schema without touching production.
- Claude Code
- Cursor
- Codex
- VS Code (Copilot)
- Windsurf
- Cline
- OpenCode
- Zed
Before and after the merge
Real data in review, no downtime in production
Real data you are allowed to use
If production holds personal data, copy it into Xata with masking rules applied and branch pull requests from the masked copy.
Learn moreShip the migration without downtime
Rehearse the migration on the branch, then apply it to production with pgroll, which serves the old and new schema side by side.
Learn moreMore branching workflows
Give every pull request its own database
Run every migration on a branch with real data before it reaches production.