12.2k

A clean database for every test run

Create a Postgres branch when the pipeline starts, run migrations and tests against it, and delete it when the job ends. Each run tests against an untouched copy of your data.

Get startedRead the docs

  • A fresh copy every run

    Each run tests against an untouched copy of your data.

  • Parallel jobs

    Each job gets its own branch. Nothing is shared.

  • Deleted at the end

    The last step removes the branch.

The problem

Flaky tests often start in the database

A shared test database turns CI into a queue. Jobs wait for each other, or they run together and trip over each other’s rows. Cleanup scripts miss a table, a migration from one branch leaks into another branch’s run, and tests fail for reasons that have nothing to do with the code under test.

Mocking the database avoids the queue but stops testing what production actually runs.

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

Create, test, delete. Every run.

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
1

Create

The first step creates a branch from your baseline: production, staging, or a masked copy. It copies no data, so it is ready in about three seconds.

2

Migrate and test

Apply pending migrations, seed if you need to, run the suite. Integration tests hit real Postgres with the real data shape.

3

Delete

The last step deletes the branch. Nothing carries over to the next run.

Set it up

Works with the CI you already run

GitHub Actions

Copy the workflows

Create a branch for the job, block the merge if the migration fails, and sweep up branches left behind by cancelled jobs.
Any other CI

GitLab, CircleCI, Buildkite, Jenkins

Install the CLI and set XATA_API_KEY to a key scoped to the one project, stored in your CI secret manager. The same commands run anywhere a shell does.
With a coding agent

Agents run the suite before you review

Agents can create a branch for the task, migrate, test, report and delete before a human sees the change. Their experiments never touch production or another agent’s branch.
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

  • Xata for coding agents

    CLI, MCP and agent skills in one place.

    Read the guide

  • MCP server

    Setup for every supported client.

    Connect MCP
Keep it cheap and safe

No bill for cancelled jobs, no exposed data

  • Cancelled jobs do not leave a bill

    If a job is cancelled before its delete step, the leftover branch can scale to zero until the cleanup workflow removes it.

    Learn more

  • Test against real data without exposing it

    If production holds personal data, branch CI runs from a masked copy. The distributions stay realistic and the values do not.

    Learn more

More branching workflows

  • One branch per pull request

    Test every migration before it merges.

    Learn more

  • One branch per preview

    A database for every Vercel and Netlify preview.

    Learn more

  • Database Branching

    How Xata branches Postgres.

    Learn more

Give every test run its own database

Stop sharing a test database. Branch it per run and delete it when the job ends.

Get startedTalk to an engineer