HomeBack to recipes
RecipesDevOpsBranch-per-PR Databases

TL;DR

Branch-per-PR Databases is a devops workflow that chains Neon + GitHub to automate a common task. Each PR gets its own Neon database branch for isolated testing. Branch is deleted automatically when the PR closes. Once configured, it saves ~6 hours/week per team, plus recovery of ~20% of engineering capacity lost to test data conflicts and runs through Claude Code, Cursor, Windsurf or any MCP-compatible AI agent.

⚡🐙
DevOpsIntermediate

Branch-per-PR Databases

Each PR gets its own Neon database branch for isolated testing. Branch is deleted automatically when the PR closes.

15 min setup, then fully automated2 MCPs requiredSaves ~6 hours/week per team, plus recovery of ~20% of engineering capacity lost to test data conflicts

How it works

⚡Neon
🐙GitHub
Automated
1PR opened — capture branch name2Create Neon branch from main database3Inject branch DATABASE_URL as PR env var+3 more steps

Partial support — 1 of 2 MCPs hostable

Hosted execution needs every MCP on the whitelist. Use the local CLI for this recipe until the missing MCPs are added.

Not yet hostable:

⚡Neon
mcpizy recipe install neon-github-branch-databases

Why this combo?

Neon's branching creates isolated database snapshots in seconds, and GitHub events tell you exactly when a PR opens or closes. Together they bring Git-style isolation to your database layer — every PR tests against its own data, completely independent of staging or other PRs.

Without this workflow

All PRs test against a shared staging database. Developers step on each other's data, migrations conflict, and test data pollutes staging indefinitely.

With MCPizy

Every PR gets its own clean database branch, injected automatically. Deleted when the PR closes. Zero coordination needed.

Business value

Concrete ROI — not marketing fluff.

Time saved

~6 hours/week per team, plus recovery of ~20% of engineering capacity lost to test data conflicts

  • Eliminates the 'who broke staging?' Slack threads — every PR has its own DB, zero cross-contamination
  • Enables true parallel development: 10 engineers on 10 branches without stepping on each other
  • Cuts flaky test rate by 70% — no more 'passed locally, failed in CI because data was stale'
  • Storage cost stays flat via auto-cleanup; copy-on-write branches are ~free vs full DB copies

Workflow steps

  1. 1
    PR opened — capture branch name
  2. 2
    Create Neon branch from main database
  3. 3
    Inject branch DATABASE_URL as PR env var
  4. 4
    Run migrations on the new branch
  5. 5
    Post DB branch URL as PR comment
  6. 6
    Delete Neon branch when PR is merged/closed

Use cases

  • Isolated database per PR so migrations never conflict
  • Automated cleanup of database branches when PRs are merged
  • Safe schema evolution testing without touching shared staging
  • Parallel CI runs that don't share test data

MCPs required

⚡

Neon

Neon MCP Server

View
🐙

GitHub

GitHub MCP Server

View

Agent prompt (copy into Claude Code)

This prompt is the workflow. Paste into Claude Code, Cursor, or Windsurf.

You are a branch-database agent. Runs on GitHub pull_request events.

On pull_request opened:
1. Call neon.create_branch(project_id, parent="main", name="pr-${pr_number}") — capture connection_uri
2. Call neon.run_migrations(branch_id, dir="./supabase/migrations") to seed schema
3. Call github.add_pr_comment with "DB branch ready — DATABASE_URL=<uri>" (mask credentials)
4. Inject DATABASE_URL as repo secret or PR env via github.update_action_secret

On pull_request closed or merged:
5. Call neon.delete_branch(project_id, branch_name) to reclaim storage

Always idempotent: if branch exists, reuse it. Never leave orphaned branches.

Trigger & credentials

How this workflow fires and what env vars you need.

.env.example
WebhookTrigger
POST /webhook/github (events: pull_request opened, closed, synchronize)
⚡Neon· 2 vars
NEON_API_KEYGet key

Neon API key

e.g. neon_...

NEON_PROJECT_IDGet key

Your Neon project ID

e.g. odd-fire-123456

🐙GitHub· 1 var
GITHUB_TOKENGet key

PAT with repo + admin:repo_hook scopes

e.g. ghp_...

One-command deploy

Install everything — MCPs, prompt, env template — in a single call.

$ mcpizy recipe install neon-github-branch-databases

✓ Installs all 2 MCP servers
✓ Writes prompt to ~/.mcpizy/prompts/neon-github-branch-databases.md
✓ Generates .env.example in current directory
✓ Ready to paste into Claude Code

Requires mcpizy CLI v1.1+ — install via npm i -g mcpizy.

Quick install (MCPs only)

15 min setup, then fully automated
$ mcpizy install neon && mcpizy install github

More DevOps recipes

🟢🐙

Auto DB Migrations on Push

Every push to main triggers a Supabase migration automatically. Schema diffs are committed and applied with zero manual steps.

🐙▲

Preview Deploy on Every PR

Open a PR and a Vercel preview URL appears as a comment within minutes. Branches are cleaned up automatically when PRs close.

🐳☁️

Container Deployment to AWS

Build, tag, push to ECR and deploy to ECS in one automated pipeline triggered by a git tag or manual dispatch.

🐙📐

Issue → Branch → PR Pipeline

A Linear issue assigned to a developer automatically creates a git branch, syncs status changes, and opens a draft PR.

Frequently asked questions

What is this workflow?

Branch-per-PR Databases is a devops automation that uses Neon + GitHub together via the Model Context Protocol. Each PR gets its own Neon database branch for isolated testing. Branch is deleted automatically when the PR closes.

How long does setup take?

Setup takes around 15 min setup, then fully automated. You install the required MCP servers with `mcpizy install neon && mcpizy install github`, connect your accounts, and the workflow is ready to run.

How much time does this workflow save?

Once running, this workflow saves ~6 hours/week per team, plus recovery of ~20% of engineering capacity lost to test data conflicts. The concrete business value: Eliminates the 'who broke staging?' Slack threads — every PR has its own DB, zero cross-contamination; Enables true parallel development: 10 engineers on 10 branches without stepping on each other.

Which MCP servers do I need for this?

You need 2 MCP servers: Neon (mcpizy install neon), GitHub (mcpizy install github). All are installable in one command via the MCPizy CLI and configured in your `.claude.json` or `.cursor/mcp.json`.

Does this work with Claude Code, Cursor, and Windsurf?

Yes. The workflow runs with any MCP-compatible AI agent — Claude Code, Claude Desktop, Cursor, Windsurf, VS Code with Copilot, and custom agents built on the MCP SDK. The MCP servers are identical across clients; only the config file path (`.claude.json` vs `.cursor/mcp.json`) changes.

Start building this workflow

Install the required MCPs from the marketplace and automate this in 15 min setup.

$ mcpizy install neon && mcpizy install github

⚡Install Neon🐙Install GitHub

Free to install. Connect your accounts and this workflow runs itself.