A database branch
for every pull request.

Tests deserve real data, not empty schemas. Copy-on-write branching gives every PR and preview environment a full Postgres instance with production-like data, created instantly and destroyed automatically.

Add this to your agent's context

Give your CI pipeline the context it needs to use Xata branches.

Most CI pipelines share a single test database across all runs. Tests interfere with each other, suites run serially to avoid corruption, and every failure is harder to triage because the environment is never clean. The alternative — provisioning a fresh database per run — has historically been too slow to be practical. Xata's copy-on-write branching makes ephemeral, production-like databases economical at any scale.

The problem

Shared test databases

Tests interfere with each other, results are flaky, and suites run serially because parallel execution corrupts shared state. Every CI failure costs the team time to triage — and the root cause is often not the code, but the environment.

shared test databaserunning checks...
pr/#101
unit
integration
e2e
pr/#102
unit
integration
e2e
pr/#103
unit
integration
e2e
waiting for shared DB lock...

Schema-only seeds miss real edge cases

Empty databases catch syntax errors, not data bugs. That nullable column, that unicode edge case, that 10-year-old row with a malformed address — seeds never reproduce them. Tests pass locally and against the seed, then fail in production against real data.

Slow provisioning

Restoring a backup or running migrations takes minutes, too slow for PR-level isolation. Teams fall back to shared databases not because it is the right choice, but because the alternative means waiting in a queue.

How it works

Xata branches use copy-on-writesemantics: a new branch shares the source database's storage until it writes something new. This makes provisioning near-instant regardless of database size, and means each branch starts from a complete, consistent snapshot of the source.

isolated branch per PR · copy-on-writerunning in parallel...
pr/#101db/pr-101
unit
integration
e2e
pr/#102db/pr-102
unit
integration
e2e
pr/#103db/pr-103
unit
integration
e2e
each PR tests against its own isolated DB

PR opens, branch created automatically

A GitHub Action or API call creates a database branch when a pull request is opened. The branch is a copy-on-write fork, created in under a second regardless of database size. No restore queue, no migration wait, no pre-warming.

Full production-like data

Every branch includes real data with real relationships and real edge cases. PII is automatically anonymized during branch creation: no manual scrubbing, no compliance risk, no special handling needed in the test code itself.

Tests run against real data in parallel

Each PR gets its own isolated branch. Run your entire test suite across 20 PRs simultaneously: no conflicts, no shared state, no flaky results from test interference. Parallelism is safe by design.

Branch destroyed on merge or close

When the PR is merged or closed, the branch is destroyed automatically. Stale branches that linger scale to zero compute: no cost for forgotten environments, no manual cleanup required.

Key capabilities

Sub-second creation

Branches are copy-on-write pointers, not copies. Creating 50 branches takes the same time as creating 1. A 500 GB database branches as fast as a 5 GB one. There is no relationship between source database size and branch creation time.

Full-fidelity data

Not seeds, not fixtures: real production data with real relationships, real edge cases, real volume. Anonymized automatically so there is no compliance risk. Your tests run against the same data shape your production code will encounter.

Data privacy & anonymization
Anonymization is applied at the branching layer, not in test code. Column-level redaction, synthetic data generation, and k-member microaggregation are all supported. Learn more about data privacy on Xata.

Parallel test runs

Every branch is isolated. Run your entire test suite across 20 PRs simultaneously without conflicts. No more serial test execution, no more shared-state flakiness. Isolation is enforced at the storage layer, not managed by the test runner.

Zero idle cost

PR closed? Branch scales to zero. Stale preview? $0. You only pay for active test runs. Scale-to-zero compute means forgotten branches never show up on your bill, and there is no incentive to reuse branches across runs.

Integration

Xata integrates into any existing CI/CD pipeline. GitHub Actions, GitLab CI, CircleCI, Jenkins: if it can call an API or run a shell command, it can create and destroy branches. No new workflow to learn, no agent to install.

Postgres for agent scale.

Use your existing Postgres. Run it better with Xata.