Create isolated Postgres branches in seconds using copy-on-write storage. Each branch gets independent compute and scales to zero when idle.
Pull requests, deployment previews, CI runs, and coding agents often change schema and data at the same time. When they share a staging database, those changes collide, tests become unpredictable, and one workflow can break another.
Modern development needs a different model: isolated databases that are created when work begins, run independently, and disappear when the work is done.
A few long-lived databases shared across the team
Changes interfere with concurrent workflows
Tests depend on data left by previous runs
Schema changes require coordination
Staging gradually drifts from production
One isolated database for each PR, preview, test run, or agent
Created on demand when work begins
Kept only for as long as the workflow needs it
Runs independently from every other branch
Removed when the workflow ends
Create a new, isolated Postgres branch from an existing database in two seconds, regardless of its size. Because Xata separates compute from copy-on-write storage, the branch starts with the parent’s schema and production-like data without copying the full database, then changes independently.
Create a branch in two seconds, no matter how large the parent database is.
Start with the parent’s schema and production-like data from the moment it is created.
Share unchanged data with the parent and store only the blocks that change.
Change schema and data without affecting the parent or any other branch.
Create a database branch for every PR. Test code against real data before merging.
Give every deployment its own database with real data, no shared staging, no conflicts.
Start every test run from a clean database. No drift, no flaky tests.
Reproduce bugs on a production-like branch without touching live data.
Give every agent its own database. Run in parallel, without multiplying costs.
Xata implements data branching at the storage layer. This makes branching extremely fast, even for terabytes of data.
In the initial state, we start with a single branch, the parent branch. The volume associated with this branch is mounted on the PostgreSQL instance. The data is organized into blocks (numbered 1 to 8 in the diagram) and an index is used to keep track of the blocks.
When a new database branch is created, initially only the index is copied. The new child branch references the same data blocks as the parent branch. This is why branching is so fast regardless of the size of the branch, because no significant amount of data is copied at this stage.
As writes are received by either the parent branch or the child branch, only the modified blocks are copied. Each branch then references its own copy of those blocks. In the diagram, this has happened for blocks 3 and 6, resulting in significant disk space savings.
Xata branches scale compute to zero when idle and wake automatically when work resumes.
Idle branches stop consuming compute while their data remains available.
Branches resume on first connection, with no manual provisioning.
Create a branch automatically as each workflow starts, and remove it when the work is done.
A developer opens a pull request.
The Xata GitHub App creates an isolated database branch for the pull request.
Connect CI jobs, migrations, and preview deployments to the branch.
The Xata GitHub App removes the database branch automatically when the pull request is merged or closed.
Keep production where it is, or move it to Xata. Either way, every pull request and deployment preview gets its own isolated Postgres branch.
Create a clone of your production database in Xata, keep it in sync with production, and have it ready for instant branching.
Run your production database on Xata with native branching, built-in high availability, read replicas, and automatic scale-to-zero.
Create isolated, production-like branches for every pull request, deployment preview, and coding agent.