Guide the user through any Neon-related task: setup, connections, branching, and advanced features. Deliver a working Neon connection, a completed feature configuration, or a specific answer from the official Neon docs.
Neon is a serverless Postgres platform that separates compute and storage to offer autoscaling, branching, instant restore, and scale-to-zero. It's fully compatible with Postgres and works with any language, framework, or ORM that supports Postgres.
Neon Documentation
The Neon documentation is the source of truth for all Neon-related information. Always verify claims against the official docs before responding. Neon features and APIs evolve, so prefer fetching current docs over relying on training data.
Fetching Docs as Markdown
Any Neon doc page can be fetched as markdown in two ways:
Request text/markdown on the standard URL: curl -H "Accept: text/markdown" https://neon.com/docs/introduction/branching
Both return the same markdown content. Use whichever method your tools support.
Finding the Right Page
The docs index lists every available page with its URL and a short description:
https://neon.com/docs/llms.txt
Common doc URLs are organized in the topic links below. If you need a page not listed here, search the docs index: https://neon.com/docs/llms.txt. Don't guess URLs.
What Is Neon
Use this for architecture explanations and terminology (organizations, projects, branches, endpoints) before giving implementation advice.
Offer to inspect existing connected Neon projects or create new ones using the Neon CLI or MCP server. If neither is set up yet, run init with the flag. Use to skip the package install prompt. Auth is handled automatically. If the user is not logged in, it opens their browser for OAuth and waits for completion before proceeding.
This installs the Neon extension (for Cursor/VS Code) or MCP server (for other agents), creates an API key, and adds the neon-postgres agent skill to the project.
If init is not suitable, the individual steps can be run non-interactively:
Use MCP server or CLI to list organizations and projects. Let the user select an existing project or create a new one.
2. Get Connection String
Use MCP server or CLI to get the connection string. Store it in .env as DATABASE_URL. Read the file first before modifying to avoid overwriting existing values.
If none: offer to create an example schema or design one together
Resume Support
If resuming setup, check what's already configured (MCP connection, .env with DATABASE_URL, dependencies, schema) and continue from the next incomplete step.
Security Reminders
Remind users to use environment variables for credentials, never commit connection strings, and use least-privilege database roles.
Connection Methods & Drivers
Use this when you need to pick the correct transport and driver based on runtime constraints (TCP, HTTP, WebSocket, edge, serverless, long-running).
Recommended: Drizzle + the right driver for your runtime
Always pair Neon with an ORM such as Drizzle for easy schema management and migrations. Pick the driver based on how the runtime treats your code:
Long-running or shared-runtime environments → node-postgres (pg). Neon Functions, and any host where the function runtime is shared across requests / runs on fluid compute (e.g. Vercel with Fluid compute), keep a module-scope process alive across many requests. Open a pg pool once at module scope and reuse it across requests.
Fully isolated serverless (Lambda-style) → Neon's serverless driver (@neondatabase/serverless). Hosts like Netlify spin up a fresh, isolated instance per request, so a persistent TCP pool can't be reused; the serverless driver queries over HTTP and is built for this.
import { drizzle } from"drizzle-orm/node-postgres";
import { Pool } from"pg";
import * as schema from"./schema";
// Created once at module scope; reused by every request the instance handles.const pool = newPool({ connectionString: process.env.DATABASE_URL, max: 5 });
const db = drizzle({ client: pool, schema });
On Vercel (Fluid compute) also attach the pool with attachDatabasePool from @vercel/functions, so the function runtime drains idle connections before an instance suspends:
import { drizzle } from"drizzle-orm/node-postgres";
import { Pool } from"pg";
import { attachDatabasePool } from"@vercel/functions";
import * as schema from"./schema";
const pool = newPool({ connectionString: process.env.DATABASE_URL });
attachDatabasePool(pool); // let the Vercel runtime manage the pooled connectionsconst db = drizzle({ client: pool, schema });
Netlify and other fully-isolated serverless — Drizzle + Neon serverless driver:
Use this for local development enablement with npx -y neonctl@latest init --agent <agent-name>, VSCode extension setup, and Neon MCP server configuration.
The Neon Admin API can be used to manage Neon resources programmatically. It is used behind the scenes by the Neon CLI and MCP server, but can also be used directly for more complex automation workflows or when embedding Neon in other applications.
Neon REST API
Use this for direct HTTP automation, endpoint-level control, API key auth, rate-limit handling, and operation polling.
Neon Auth is also embedded in the Neon JS SDK. Depending on your use case, you may want to use the Neon JS SDK instead of Neon Auth alone. See https://neon.com/docs/connect/choose-connection.md for more details.
Neon Infrastructure as Code (neon.ts)
neon.ts is Neon's branch config and infrastructure-as-code file: declare which services your branches have, get type-safe env vars, and program per-branch compute — all in TypeScript (see the neon skill for the full reference). Postgres always exists on every branch, so you never declare the database itself; what you codify here is the Postgres-adjacent surface — Neon Auth, the Data API, and per-branch compute settings (autoscaling and scale-to-zero).
Reconcile the declaration from the CLI — the Neon equivalent of terraform plan / apply:
neonctl config status # print the branch's live config
neonctl config plan # dry-run diff of what apply would change
neonctl config apply # provision the declared services / settings
neonctl deploy # alias for `neonctl config apply`
Because neonctl checkout applies the policy as it creates a branch, a fresh branch comes up with these compute settings (and Auth / Data API) already in place. Checking out an existing branch never reconciles it — run neonctl deploy to apply changes.
Since neon.ts is TypeScript, invalid combinations fail to compile with an actionable message: the Data API verifies requests with Neon Auth by default, so dataApi: true without auth: true is a type error (the fix — auth: true, or authProvider: 'external' with a jwksUrl — is in the message). See the neon skill's type-safe config note.
Read the resulting env back, typed and validated against the policy, with parseEnv from @neondatabase/env:
For detailed branch creation workflows (normal vs schema-only branches, reset-from-parent, CLI/MCP selection), use the neon-postgres-branches skill if available
Or fetch the full branching skill from the following URL:
This supplement is maintained by the repository sync pipeline. It keeps the
imported upstream skill usable inside this curated collection when the upstream
source is intentionally concise.
Common Patterns
1. Confirm that the user's task matches the skill trigger.
2. Read the relevant project files or user-provided context before acting.
3. Choose the smallest reversible action that advances the task.
4. Run the verification command or manual check that proves the result.
5. Report the outcome, evidence, and any remaining risk.
Boundaries
Prefer the upstream workflow for Neon Postgres; this section only adds local quality
guardrails.
Do not invent project facts when required files, vaults, services, or tools are
unavailable.
Stop and ask for clarification when the next action could overwrite user work,
expose private data, or change production state.
