Introducing the Xata GitHub App | xata
11.9k<br>11.9kLog inGet Started
Back to Blog<br>Introducing the Xata GitHub App<br>Giving every pull request its own copy-on-write branch of the production Postgres you already run, even at terabyte scale. Ready in about three seconds, gone when the PR closes.
By:<br>Claudiu Dascalescu<br>Published:<br>Jul 8, 2026<br>Reading time:<br>4 min read
Back to Blog<br>Tags<br>Xata
Featured<br>A thousand Postgres branches for $1Inside Xatastor: ZFS + NVMe-oF for Postgres databasesIntroducing Xata OSS: Postgres platform with branching
Today we're launching the Xata GitHub App. Connect a repository to a Xata project, and every pull request gets its own isolated Postgres branch. Each branch is a copy-on-write clone off the Postgres you already run on RDS, Aurora, Cloud SQL, or self-hosted.<br>It takes about three seconds to create, even past a terabyte, and you pay for the diffs rather than a full replica. The branch appears when the PR opens and is deleted when the PR closes.
Why we built the GitHub App<br>If you test database changes, you've probably picked one of two bad options. You test against a seed database, which is quick to spin up but doesn't look like production, so the migration that was green in CI still locks the table at 2am. Or you test against a real copy, which means dump and restore: at any real size that copy takes 30 minutes to over an hour, and it keeps growing. So most teams settle for a single shared staging database, and then they wait in line for it.<br>Both options cost you something. Seed data misses the bugs that only show up on real rows. Shared staging turns every review into a queue. The test itself is cheap. Building a realistic database to run it against is the expensive part.<br>One of our BYOC customers running Postgres at terabyte scale put the gap in concrete terms:<br>"Currently in our QA environment it's very redacted mock data of a very small subset of production, not the full terabyte-scale database, more like a couple of gigabytes... it just isn't very useful because it's not prod-like at all. From QA alone we'd expect something like 100 branches running concurrently at most, but we'd also need database branches from local dev environments, so a max of around 200 concurrently seems reasonable. I suspect it would take more than a year to surpass that."
They need on the order of 100 concurrent QA branches of a 4TB Postgres database, each carrying production-shaped data rather than a shared mock subset. Building that with dump-and-restore at terabyte scale is the math that breaks.<br>How it works<br>You install the app once and connect a repository to a Xata project. After that, it watches your pull requests.<br>When a PR opens, the app creates a Postgres branch from your connected database and comments the connection details on the PR. Push more commits and the branch is there for your checks to use. Merge or close the PR and the app deletes it. Creation takes about three seconds, and a branch scales to zero while the PR is idle, so an open PR you forgot about doesn't run up the bill.<br>A branch of the Postgres you already run<br>A preview database is only worth having if it behaves like production. A database built from a seed file doesn't, and a nightly copy of your data is already stale by the time you branch it. This is where the branch earns its place: it's copy-on-write off the Postgres you already run, so it reflects your real, current data without moving your database anywhere. No migration to a new platform, no second synced copy on someone else's infrastructure, no proprietary storage layer in between. It's your database, branched, in your own cloud.<br>That's what makes it worth testing against. The schema change that passes on seed data and fails on real rows, a required column added where existing rows are null, an audit trigger that never made it onto the new schema: all of it surfaces at review instead of in production.<br>Less to maintain in your pipeline<br>Teams have been building this by hand for a while, wiring branch creation into GitHub Actions with the Xata CLI. One of them put it to us directly:<br>"Now we use GitHub Actions to create the database branch; we really need a GitHub App to handle this."
That still works, and it's the right call when you want full control. The GitHub App is another way to run the same workflow, with the branch lifecycle handled for you.<br>The app owns creating and deleting the branch across the PR's life. A slim CI job that runs your migrations against the branch can stay. What goes away is the bookkeeping: the create step, the delete step, and the cleanup when someone abandons a PR. Install once, map the repos you want, and the branches look after themselves.<br>What comes next<br>Branch-per-PR is the starting point. The same mechanism gives every developer and every QA environment its own branch, so an expensive query or a long test run never lands on shared data. And a pull request is a pull request whether a person or an agent opens it: an AI coding agent...