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.

Read the docsGet started

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. 01

    Pull request opens

    A developer or a coding agent opens a pull request.

  2. 02

    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. 03

    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. 04

    The branch is deleted on close

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

Under the hood

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

Automatic

GitHub App + Vercel or Netlify

  • GitHub
  • Vercel
  • Netlify
  1. 01Install the Xata GitHub App and link the repo
  2. 02Add one build step that sets DATABASE_URL
  3. 03Every preview gets its own branch
Or run it from any CI
Agent-driven

Let your coding agent do it

  • Claude Code
  • Cursor
  • Codex
  1. 01The agent creates a branch
  2. 02It runs the migration and seeds the data it needs
  3. 03It opens the pull request, so the preview builds on a migrated database
Try it
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