Skip to content

A Database Branch for Every Vercel Preview

4 min readVercelBranchingPostgreSQL

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:

  1. Connect Vercel. From the Integrations page in the dashboard, click Connect Vercel and authorize via OAuth. The connection is shared with your team.
  2. 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.
  3. 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.
  4. 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: 9 engines branch on Layerbase Cloud: PostgreSQL, MySQL, MariaDB, Redis, Valkey, FerretDB, libSQL, SQLite, and DuckDB (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.

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.

Something not working?