Neon Postgres Branches · neondatabase/agent-skills · Skills Docs

Skills

Skill 5 of 9

Neon Postgres Branches

Choose and create the right Neon branch type for testing and development.

7 minutes · 1,564 words · 25 sections

Install

$ npx skills add neondatabase/agent-skills --skill neon-postgres-branches

$ npx skills add neondatabase/agent-skills

» /plugin marketplace add neondatabase/agent-skills

The first command installs just this skill, by the name in its SKILL.md; the second installs the whole repository.

FIRST: Use the parent neon skill for a Neon overview, getting started with Neon, Neon development best practices, and more.

If the neon skill is not installed, fetch it from https://neon.com/docs/ai/skills/neon/SKILL.md (opens in a new tab) or install it with:

neon skills -s neon -y

Lakebase Postgres Branching

Outcome: a created Neon branch — or a clear, actionable next step if creation cannot proceed. Choose the correct branch type, then execute branch creation with the CLI (or MCP where the CLI isn’t usable).

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

Support both the Neon CLI and the Neon MCP server, but default to the CLI. Use MCP only when the CLI is unavailable or blocked in your environment, cannot be authenticated, or the user explicitly asks for MCP.

CLI link: https://neon.com/docs/cli/quickstart.md (opens in a new tab)
MCP link: https://neon.com/docs/ai/neon-mcp-server.md (opens in a new tab)

Selection order

Check the CLI first:
- Run neon --version to confirm the CLI is installed.
- Run neon projects list to confirm auth/context.
If the CLI is missing, direct installation via quickstart.
If the CLI is installed but not authenticated, guide the user through neon auth (or API key auth), then continue.
Switch to MCP when the CLI cannot be used — no CLI access in the environment, execution blocked, or authentication not possible — or when the user explicitly asks for MCP. Confirm Neon MCP tools are available and authenticated (for example, listing projects works), then follow the MCP branch flow below.
If neither path is successful, use the Neon REST API:
- https://neon.com/docs/guides/branching-neon-api.md (opens in a new tab)

MCP branch flow

Choose normal vs schema-only based on data sensitivity and migration-testing goals.
Use branch tools (for example, create_branch) to create the 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.

Link: https://neon.com/docs/introduction/branching.md (opens in a new tab)

Steps

Settle the tool path first (see Selection order): verify the CLI with neon --version, and fall back to MCP only if the CLI isn’t usable.
Ensure project context is set (neon set-context --project-id <your-project-id>) or include --project-id on commands.

Create the branch:

neon branches create \
  --name <branch-name> \
  --parent <parent-branch-id-or-name> \
  --expires-at 2026-12-15T18:02:16Z

Optionally fetch a connection string for the new branch:
```
neon connection-string <branch-name>
```

Create a Schema-Only Branch (Beta, Sensitive Data)

Use this when users must not copy production rows into the test branch.

Link: https://neon.com/docs/guides/branching-schema-only.md (opens in a new tab)

Steps

Settle the tool path first (see Selection order): verify the CLI with neon --version, and fall back to MCP only if the CLI isn’t usable.

Create the schema-only branch:

neon branches create \
  --name <schema-only-branch-name> \
  --parent <parent-branch-id-or-name> \
  --schema-only \
  --expires-at 2026-12-15T18:02:16Z

If multiple projects exist, include --project-id:

neon branches create \
  --name

Beta Support Guidance (Mandatory)

Schema-only branching is in Beta. If users report unexpected behavior, errors, or missing capabilities:

Ask them to share feedback in the Neon Console:
- https://console.neon.tech/app/projects?modal=feedback (opens in a new tab)
Recommend opening a support conversation in the Neon Discord:
- https://neon.com/discord (opens in a new tab)

Reset from Parent

Use this when a child branch has drifted and the user wants a clean refresh from the parent branch’s latest schema and data.

Link: https://neon.com/docs/guides/reset-from-parent.md (opens in a new tab)

What it does

Fully replaces the child branch schema and data with the parent’s latest state.
Does not merge; local changes on the child branch are lost.
Keeps the same connection details, but active connections are briefly interrupted during reset.

Development or staging branch is too far behind production.
User wants to start a new feature from a clean parent-aligned state.
Team wants to refresh staging from production for consistent testing baselines.

Hard constraints and blockers

Only child branches can be reset (root branches and schema-only root branches cannot be reset from parent).
If the target branch has children, reset is blocked until those child branches are removed.
After a parent branch is restored from snapshot, reset-from-parent may be unavailable for up to 24 hours.
Reset-from-parent always uses the current parent state; use Instant restore for point-in-time recovery needs.

CLI usage

neon branches reset <id|name> --parent --preserve-under-name <backup-branch-name>

If project context is not already set, include the project ID:

neon branches reset <id|name> --parent --preserve-under-name <backup-branch-name> --project-id <project-id>

--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 .env DATABASE_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.

npm i @neon/config

// neon.ts
import { defineConfig } from "@neon/config/v1";

export default defineConfig({
  branch: (branch) => {
    if (branch.exists) return {}; // never reconcile existing branches
    if (branch.isDefault) return { protected: true };

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 (opens in a new tab), preview-branches-with-vercel (opens in a new tab), or preview-branches-with-fly (opens in a new tab) 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 (opens in a new tab) 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.”

Agent output shape:

Recommend a normal branch and explain why.
Share docs link: https://neon.com/docs/introduction/branching (opens in a new tab)
Check the tool path first (CLI with neon --version; MCP only if the CLI isn’t usable).
Provide commands:
- neon branches create --name migration-test --parent main --expires-at 2026-12-15T18:02:16Z
- neon connection-string migration-test

Example 2: Sensitive data development workflow

User input: “We cannot copy production data because of compliance.”

Agent output shape:

Recommend schema-only branch and explain why.
Share docs link: https://neon.com/docs/guides/branching-schema-only (opens in a new tab)
Check the tool path first (CLI with neon --version; MCP only if the CLI isn’t usable).
Provide command:
- neon branches create --name compliance-dev --parent main --schema-only --project-id <your-project-id> --expires-at 2026-12-15T18:02:16Z
Mention Beta support path:
- https://console.neon.tech/app/projects?modal=feedback (opens in a new tab)
- https://neon.com/discord (opens in a new tab)

About this skill

Trigger

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, resetting a branch from its parent, branch expiration and CI/CD branch lifecycles, or branch creation via Neon CLI or Neon MCP. Triggers include "Neon branch", "test migrations safely", "branch production data", "schema-only branch", "reset branch", "branch per PR" and "sensitive data testing".

The verbatim description from this skill’s front matter — the string an agent matches on to decide whether to load it.

Also published for: Alternate — collapsed into this chapter because the copies are the same skill.
Source: skills/neon-postgres-branches/SKILL.md

Colophon for this issue

Colophon

How this issue was made

Source

github.com/neondatabase/agent-skills, branch main, last pushed 23 September 2026.

Licence

Apache-2.0 — the text of every skill is reproduced unmodified, frontmatter included, under the upstream licence.

Discovery

9 skills found by walking the repository tree for SKILL.md, not by matching a directory convention. 2 distinct layouts observed: evals/neon-postgres-egress-optimizer/.claude/skills/*/SKILL.md, skills/*/SKILL.md.

Authorship

1 of 9 skills are installed into the repository rather than published from it. They are shelved in the closing “Credited skills” part and remain the work of their own authors. A skill counts as credited when its only copy lives under one agent’s dot directory; visible directories, per-agent mirror sets, and skills installable from this repository on skills.sh all count as published.

Duplicates collapsed

8 mirror copies folded into their canonical skill — republished for Alternate. Copies match on content hash and on position once a leading per-agent prefix is stripped, because the same skill is routinely shipped under a dozen agent directories with a dozen different hashes.

Issue colours

Resolved from a deterministic hash of the owner name. Two accent tones are generated per issue and each is proven against its own ground before it ships: a single accent that passes AA on both light and dark paper is arithmetically impossible.

Heading repairs

1 repair applied to this skill so the document has one h1 and no skipped levels:

Shifted “25 headings” from h1 to h2 so the skill title is the only h1.

Spec compliance

1 editorial note across 1 of 9 skills. They are printed in the margin of each skill rather than as errors here.

Score Eval — 1 note