A Database Branch for Every Vercel Preview
Short version: connect Vercel to Layerbase once, map a project, and every preview deployment gets its own writable database branch forked from production, with the connection string injected into Vercel's environment variables for the right deployments. Isolated compute on a shared dev database is not isolation, which is why previews go flaky: migrations collide, seed data rots, and one reviewer's test delete breaks somebody else's demo. The integration covers PostgreSQL today; branching itself covers 16 engines.
Vercel got preview deployments right a long time ago: every branch gets its own URL, its own build, its own serverless functions. The part that never got solved is sitting one layer down. Almost every team wires those beautifully isolated previews to a single shared dev database, and then wonders why previews are flaky.
The Layerbase Vercel integration closes that gap. Connect once, map a project, and your preview deployments run against an isolated, writable database branch forked from production, with the connection string written into Vercel's environment variables for you. It is live today for PostgreSQL databases on Layerbase Cloud.
The shared dev database is the actual problem
Isolated compute plus shared state is not isolation. Concretely:
Migrations collide. Your PR adds a column. A teammate's PR drops a table. Both preview deployments run their migrations against the same shared database, and now both previews are testing a schema that exists in neither PR. The failure shows up as a confusing runtime error in whichever preview deployed second, usually reviewed by someone who has no idea another branch is involved.
Seed data drifts. The shared dev database starts as a clean seed and decays into an archaeological site: half-deleted test users, rows from a feature that shipped in March, whatever the last person's manual QA left behind. Previews stop telling you "does this change work" and start telling you "does this change work against six months of sediment."
Writes leak between reviews. A reviewer deletes a record to test an edge case in one preview and silently breaks the demo a PM is walking through in another. Nobody did anything wrong; the architecture did.
Teams paper over this with reset scripts and Slack etiquette ("don't touch staging data today"). The real fix is the same one Vercel applied to compute: give each preview its own copy.
What the integration does
A Layerbase database branch is a full, writable copy of its parent. On branch-ready storage a branch is an instant copy-on-write fork, not a byte-for-byte copy, so a preview gets its own production-shaped data in seconds without doubling your storage bill.
The integration keeps the wiring in sync with your git branches:
- Connect Vercel. From the Integrations page in the dashboard, click Connect Vercel and authorize via OAuth. The connection is shared with your team.
- Map a project. Pick the production database to fork from and the Vercel project. Layerbase reads the project's production branch for you. Your production git branch keeps pointing at the main database; your staging git branch gets its own database branch forked from production.
- Environment variables are injected. The branch's pooled connection string is written to the variable you choose (default
DATABASE_URL), scoped to the right deployments: the production value on production, the branch value on the preview deployments for that git branch. Your app code reads the same variable it always did and lands on the right database automatically. - Reset on merge, if you want it. An optional toggle re-forks the staging branch from production whenever it deploys, so your preview data never drifts far from reality. The connection string does not change on reset, so nothing downstream needs re-wiring. It is off by default because it is destructive to whatever was in the branch.
Removing a mapping cleans up the environment variable the integration created and leaves your production variable and the database branch untouched.
Which engines branch
The Vercel integration works with PostgreSQL today, with more engines to follow. Database branching itself is broader: 16 engines branch on Layerbase Cloud: PostgreSQL, MySQL, MariaDB, Redis, Valkey, FerretDB, libSQL, SQLite, DuckDB, TypeDB, ClickHouse, Meilisearch, Qdrant, QuestDB, InfluxDB, and Weaviate (MongoDB workloads branch via FerretDB). If you would rather wire branching to your CI yourself, the same branch API the integration uses also powers a drop-in GitHub Actions workflow that creates and tears down a branch per pull request.
FAQ
Why do preview deployments need their own database?
Because isolated compute plus shared state is not isolation. Two open pull requests running migrations against the same database leave both previews testing a schema that exists in neither branch, and the error surfaces in whichever preview deployed second, usually for a reviewer with no idea another branch is involved.
Does a branch copy all my data?
On branch-ready storage it is an instant copy-on-write fork rather than a byte-for-byte copy, so the branch shares blocks with its parent and only what you change costs anything. A preview gets production-shaped data in seconds without doubling your storage bill.
Which environment variable does the integration set?
Whichever one you pick, defaulting to DATABASE_URL, and it is scoped per deployment: the production value on production, the branch value on the preview deployments for that git branch. Your app code reads the same variable it always did.
What happens to my data when a branch resets?
The reset toggle re-forks the staging branch from production on deploy, which wipes whatever was in the branch. That is why it is off by default. The connection string survives a reset, so nothing downstream needs re-wiring.
What happens if I remove the mapping?
The integration deletes the environment variable it created and leaves your production variable and the database branch alone. Nothing of yours gets cleaned up on your behalf.
Does this work with engines other than Postgres?
The Vercel integration is PostgreSQL today. Branching itself is broader: 16 engines branch on Layerbase Cloud, and the same branch API the integration uses also drives a drop-in GitHub Actions workflow if you would rather wire it into CI yourself.
Try it
The setup is a few minutes end to end: create a Postgres database (free, no card), flip on branching storage in settings, and connect your Vercel project. The full walkthrough, including the environment-variable details and the reset-on-merge behavior, is in the Vercel integration guide.
Your previews already have their own URLs. They should have their own data too.
Keep reading
- Preview environment platforms in 2026: what is in the database when the preview comes upEvery platform on this list will give a pull request its own URL. The question that sorts them is what is in the database behind that URL: nothing, a restore of last night's backup, or the live data as of right now. Here is where each of eleven platforms lands, quoted from their own docs, and what a preview costs while the PR sits open.
- pgrun alternatives: a Postgres branch for every agent, on your own machinepgrun gives every agent, CI run, or pull request a disposable branch of your production Postgres. Here is what it actually does and where its limits are, how to get the same workflow locally for free with the Layerbase CLI, and the hosted alternatives worth comparing: Neon, Xata, and DBLab Engine.
- Aiven vs Vercel Postgres: a decision guideVercel Postgres is not a product anymore, so this is really Aiven versus a Neon project bought through the Vercel Marketplace. Which one fits, what each costs as of September 2026, and the questions to put in front of a proof of concept before anyone signs.
- Northflank alternatives: a preview environment is not a database branchNorthflank gives every pull request its own stack, and the database in that stack starts empty unless you seed it or restore it from a backup you already had. Here is exactly how their forks work, what a copy-on-write branch does differently, what each one costs while a PR sits open, and the cases where Northflank is the right answer.