12.2k

A database for every preview deployment

Each Vercel or Netlify preview connects to its own Postgres branch with production-shaped data. When the preview goes away, so does the branch.

Get startedRead the docs

  • Copy-on-write

    Each preview branch starts from production-shaped data without copying it.

  • Its own DATABASE_URL

    Every preview deployment connects to its own Postgres.

  • Gone with the preview

    The branch is deleted when the pull request closes.

The problem

A preview is only as real as the data behind it

Reviewers judge a change by what they see in the preview. If the data behind it is shared or fake, they are judging the wrong thing. Seed data never has the shape, the volume or the edge cases of the rows your users actually create.

  • Migrations break other previews

    A schema change in one preview breaks every other preview on the same database.

  • Test records leak

    Data created while reviewing one change shows up in the next review.

  • Nobody knows the schema

    Staging drifts, and nobody can say which schema it is on today.

How it works

One branch per preview, created and deleted for you

1

Pull request opens

A developer or a coding agent opens a pull request.

2

A database branch is created

The Xata GitHub App creates a branch from your root branch, named after the Git branch. It copies no data, so it is ready in about three seconds.

3

The preview builds against the branch

Vercel and Netlify expose the Git branch name at build time. A short build step turns it into that branch’s connection string and passes it to the app as DATABASE_URL.

4

The branch is deleted on close

When the pull request merges or closes, the GitHub App deletes the branch.

How copy-on-write branching works
Xata separates Postgres compute from copy-on-write storage. See the architecture.
Set it up

Two ways to set it up

With GitHub and your deploy platform

GitHub App plus Vercel or Netlify

Install the Xata GitHub App and link the repository, then wire the preview build to the branch. Prefer your own pipeline? The CLI runs the same lifecycle from any CI step.
With a coding agent

The preview builds on a database that is already migrated

The agent creates the branch, runs the migration, seeds what it needs and opens the pull request. The preview builds against a database that already has the change applied.
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

Forgotten previews cost nothing, real data stays private

  • Forgotten previews cost nothing to keep

    Turn on scale to zero for child branches and a preview nobody opens releases its compute until the next connection.

    Learn more

  • Real data you are allowed to use

    If production holds personal data, copy it into Xata with masking rules applied and branch previews from the masked copy.

    Learn more

More branching workflows

  • One branch per pull request

    Test every migration before it merges.

    Learn more

  • One branch per CI/CD

    A clean database for every test run.

    Learn more

  • Database Branching

    How Xata branches Postgres.

    Learn more

Give every preview its own database

Production-shaped data behind every Vercel and Netlify preview, deleted when the preview goes away.

Get startedTalk to an engineer