Choose and create the right Neon branch type for testing and development. Use when users ask about Neon branching, migration testing with real data, isolated test environments, schema-only branch workflows for sensitive data, or branch creation via Neon CLI or Neon MCP. Triggers...
Instrucciones de origen · Vista previa de solo lectura
name
neon-postgres-branches
description
Choose and create the right Neon branch type for testing and development. Use when users ask about Neon branching, migration testing with real data, isolated test environments, schema-only branch workflows for sensitive data, or branch creation via Neon CLI or Neon MCP. Triggers...
Use this skill when you need choose and create the right Neon branch type for testing and development. Use when users ask about Neon branching, migration testing with real data, isolated test environments, schema-only branch workflows for sensitive data, or branch creation via Neon CLI or Neon MCP. Triggers...
The outcome of this skill should be a created Neon branch (or a clear, actionable next step if creation cannot proceed).
Choose the correct branch type, then execute branch creation via MCP or CLI.
Normal branch for realistic migration and query testing with real data.
Schema-only branch (Beta) for sensitive data workflows where structure is needed without copying rows.
Branch Type Decision
Use this decision rule first:
If the user wants to test complex migrations, performance, or behavior against production-like data, choose a normal branch.
If the user needs to avoid copying sensitive data, choose a schema-only branch.
If the request is ambiguous, ask one clarifying question:
"Do you need realistic data for testing, or only schema structure because the data is sensitive?"
Tool Selection: CLI or MCP
Always support both Neon CLI and Neon MCP server. Prefer the tool the user already has installed and authenticated.
Choose normal vs schema-only based on data sensitivity and migration-testing goals.
Use branch tools (for example, ) to create the branch.
create_branch
Validate with read tools (for example, describe_branch).
For migration workflows, prefer branch-based migration flows before applying to main.
Create a Normal Branch (Preferred for Real-Data Migration Testing)
Use this when the user needs realistic testing conditions.
Real production-like data can expose edge cases your seed or data migration scripts miss, which helps catch migration issues before going live.
--preserve-under-name keeps the pre-reset state as a backup branch for rollback, but adds one extra branch to clean up later.
Optional context setup to avoid repeating --project-id:
neon set-context --project-id <project-id>
Console and API usage
Console: Open the target child branch, then select Reset from parent from Actions.
API: Use the restore endpoint for the branch and set source_branch_id to the parent branch ID.
Notes and Caveats
Schema-only branches are for structure-only cloning and sensitive/compliant data controls.
Schema-only branches are independent root branches (no parent branch and no shared history), so reset-from-parent does not apply.
For migration testing that depends on real-world row shapes, volumes, and edge cases, prefer normal branches.
Root branch allowances and per-branch storage limits can cap how many schema-only branches users can create.
If a user is unsure, default recommendation is:
Normal branch for migration validation.
Schema-only branch for compliance and privacy constraints.
Useful Workflow Patterns
If the user asks for process recommendations (not just a single command), suggest these:
One branch per PR: Create branch when PR opens, delete when merged/closed, keep migration tests isolated.
One branch per test run: Create branch at pipeline start, run migrations/tests, delete at end for deterministic CI.
One branch per developer: Isolated dev environments with production-like shape; avoid team collisions on shared test data.
PII-aware branching: If production has sensitive data, derive dev/PR branches from an anonymized branch or use schema-only branches.
Ephemeral lifecycle hygiene: Set branch expiration and automate cleanup so old branches do not accumulate avoidable storage/history cost.
Post-creation environment update prompt
After branch creation, ask whether the user wants to update local environment credentials to point at the new branch.
Ask: "Do you want me to update your .envDATABASE_URL to this new branch connection string?"
If yes, write the new branch connection string to the requested env file/key.
If no, leave credentials unchanged and share the connection string for manual use.
Never overwrite an existing env key without explicit confirmation.
Neon Infrastructure as Code (neon.ts)
Beyond creating branches imperatively (CLI / MCP / API above), you can program what configuration new branches receive declaratively in neon.ts — Neon's infrastructure-as-code file (see the neon skill for the full reference). The branch property is a function of the branch being evaluated that returns its settings, so every branch born from your project gets a consistent lifecycle and compute profile without per-branch flags.
The closure receives a read-only descriptor of the target branch — name, exists, isDefault, parentId, and more — and returns the tuning to apply: parent, ttl (auto-expiry), protected, and postgres.computeSettings. This is the declarative complement to the Ephemeral lifecycle hygiene and per-PR / per-test patterns above: instead of remembering --expires-at on every neon branches create, the TTL and compute profile live in version control and apply to every matching branch.
Because neon checkout applies this policy when it creates a branch, a fresh preview/* or dev-* branch comes up already expiring and scaled-to-zero. Checking out an existing branch doesn't reconcile it — run neon deploy (alias for neon config apply) to apply changes to a branch that already exists.
Branching in CI/CD
Common CI/CD use cases for Neon branches:
Per-PR preview deployments: Branch on PR open, deploy the preview against it, delete on close. Each PR gets an isolated database branch. Injecting the branch's DATABASE_URL into the deployed app is hosting-provider-specific — see preview-branches-with-cloudflare, preview-branches-with-vercel, or preview-branches-with-fly for tested patterns.
Migration testing in CI: Run risky schema changes against a branch with production-like data before merge.
Schema diff visibility: Use the schema-diff GitHub Action to auto-comment a DB-layer diff on the PR.
Examples
Example 1: Migration testing with realistic data
User input: "I need to test a risky migration against production-like data."
