home / skills / openclaw / skills / neon-postgres

neon-postgres skill

/skills/andrelandgraf/neon-postgres

This skill guides you through Neon Serverless Postgres setup, branching, auth, and APIs, helping you implement scalable, serverless Postgres workflows.

npx playbooks add skill openclaw/skills --skill neon-postgres

Review the files below or copy the command above to add this skill to your agents.

Files (2)
SKILL.md
7.2 KB
---
name: neon-postgres
description: Guides and best practices for working with Neon Serverless Postgres. Covers getting started, local development with Neon, choosing a connection method, Neon features, authentication (@neondatabase/auth), PostgREST-style data API (@neondatabase/neon-js), Neon CLI, and Neon's Platform API/SDKs. Use for any Neon-related questions.
---

# Neon Serverless Postgres

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:

1. **Append `.md` to the URL** (simplest): https://neon.com/docs/introduction/branching.md
2. **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.

Link: https://neon.com/docs/ai/skills/neon-postgres/references/what-is-neon.md

## Getting Started

Use this for first-time setup: org/project selection, connection strings, driver installation, optional auth, and initial schema setup.

Link: https://neon.com/docs/ai/skills/neon-postgres/references/getting-started.md

## 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).

Link: https://neon.com/docs/ai/skills/neon-postgres/references/connection-methods.md

### Serverless Driver

Use this for `@neondatabase/serverless` patterns, including HTTP queries, WebSocket transactions, and runtime-specific optimizations.

Link: https://neon.com/docs/ai/skills/neon-postgres/references/neon-serverless.md

### Neon JS SDK

Use this for combined Neon Auth + Data API workflows with PostgREST-style querying and typed client setup.

Link: https://neon.com/docs/ai/skills/neon-postgres/references/neon-js.md

## Developer Tools

Use this for local development enablement with `npx neonctl@latest init`, VSCode extension setup, and Neon MCP server configuration.

Link: https://neon.com/docs/ai/skills/neon-postgres/references/devtools.md

### Neon CLI

Use this for terminal-first workflows, scripts, and CI/CD automation with `neonctl`.

Link: https://neon.com/docs/ai/skills/neon-postgres/references/neon-cli.md

## Neon Admin API

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.

Link: https://neon.com/docs/ai/skills/neon-postgres/references/neon-rest-api.md

### Neon TypeScript SDK

Use this when implementing typed programmatic control of Neon resources in TypeScript via `@neondatabase/api-client`.

Link: https://neon.com/docs/ai/skills/neon-postgres/references/neon-typescript-sdk.md

### Neon Python SDK

Use this when implementing programmatic Neon management in Python with the `neon-api` package.

Link: https://neon.com/docs/ai/skills/neon-postgres/references/neon-python-sdk.md

## Neon Auth

Use this for managed user authentication setup, UI components, auth methods, and Neon Auth integration pitfalls in Next.js and React apps.

Link: https://neon.com/docs/ai/skills/neon-postgres/references/neon-auth.md

Neon Auth is also embedded in the Neon JS SDK - so depending on your use case, you may want to use the Neon JS SDK instead of Neon Auth. See https://neon.com/docs/ai/skills/neon-postgres/references/connection-methods.md for more details.

## Branching

Use this when the user is planning isolated environments, schema migration testing, preview deployments, or branch lifecycle automation.

Key points:

- Branches are instant, copy-on-write clones (no full data copy).
- Each branch has its own compute endpoint.
- Use the neonctl CLI or MCP server to create, inspect, and compare branches.

Link: https://neon.com/docs/ai/skills/neon-postgres/references/branching.md

## Autoscaling

Use this when the user needs compute to scale automatically with workload and wants guidance on CU sizing and runtime behavior.

Link: https://neon.com/docs/introduction/autoscaling.md

## Scale to Zero

Use this when optimizing idle costs and discussing suspend/resume behavior, including cold-start trade-offs.

Key points:

- Idle computes suspend automatically (default 5 minutes, configurable) (unless disabled - launch & scale plan only)
- First query after suspend typically has a cold-start penalty (around hundreds of ms)
- Storage remains active while compute is suspended.

Link: https://neon.com/docs/introduction/scale-to-zero.md

## Instant Restore

Use this when the user needs point-in-time recovery or wants to restore data state without traditional backup restore workflows.

Key points:

- Restore windows depend on plan limits.
- Users can create branches from historical points-in-time.
- Time Travel queries can be used for historical inspection workflows.

Link: https://neon.com/docs/introduction/branch-restore.md

## Read Replicas

Use this for read-heavy workloads where the user needs dedicated read-only compute without duplicating storage.

Key points:

- Replicas are read-only compute endpoints sharing the same storage.
- Creation is fast and scaling is independent from primary compute.
- Typical use cases: analytics, reporting, and read-heavy APIs.

Link: https://neon.com/docs/introduction/read-replicas.md

## Connection Pooling

Use this when the user is in serverless or high-concurrency environments and needs safe, scalable Postgres connection management.

Key points:

- Neon pooling uses PgBouncer.
- Add `-pooler` to endpoint hostnames to use pooled connections.
- Pooling is especially important in serverless runtimes with bursty concurrency.

Link: https://neon.com/docs/connect/connection-pooling.md

## IP Allow Lists

Use this when the user needs to restrict database access by trusted networks, IPs, or CIDR ranges.

Link: https://neon.com/docs/introduction/ip-allow.md

## Logical Replication

Use this when integrating CDC pipelines, external Postgres sync, or replication-based data movement.

Key points:

- Neon supports native logical replication workflows.
- Useful for replicating to/from external Postgres systems.

Link: https://neon.com/docs/guides/logical-replication-guide.md

Overview

This skill provides concise guidance and best practices for working with Neon Serverless Postgres. It covers getting started, local development, connection choices, Neon-specific features (branching, autoscaling, scale-to-zero), authentication, Neon JS patterns, CLI usage, and Platform APIs/SDKs. Use it as a reference for practical Neon workflows and troubleshooting.

How this skill works

The skill summarizes Neon architecture and operational patterns, then maps common developer tasks to the right Neon docs and tooling. It explains how to pick connection methods (TCP, HTTP, WebSocket, serverless drivers), use Neon Auth and Neon JS for combined auth + data flows, and manage resources via CLI or platform APIs. It also highlights runtime trade-offs like cold starts, pooling, and branching strategies.

When to use it

  • Setting up a new Neon project or choosing an org/project and connection string
  • Deciding between direct Postgres drivers, serverless driver, or Neon JS SDK for your runtime
  • Implementing authentication and user-managed data access with Neon Auth or Neon JS
  • Developing locally and integrating the Neon CLI, MCP server, or VSCode tooling
  • Automating Neon resources with the REST API, TypeScript SDK, or Python SDK
  • Planning branching, point-in-time restores, read replicas, or scale-to-zero behavior

Best practices

  • Always verify runtime-sensitive behavior against the official Neon docs before production changes
  • Use connection pooling (-pooler endpoints) for serverless or high-concurrency environments
  • Prefer the serverless driver or Neon JS in edge/serverless runtimes to avoid long-lived TCP connections
  • Create branches for isolated schema changes and use instant restore or time-travel for rollbacks
  • Automate resource management via CLI or APIs and store API keys securely in CI/CD secrets
  • Measure cold-start impact when enabling scale-to-zero and tune suspend intervals based on workload

Example use cases

  • Local development: initialize a project with neonctl, run a local MCP server, and test branches
  • Serverless APIs: use @neondatabase/serverless or Neon JS to run short-lived queries from edge functions
  • Feature preview environments: create branch per PR for schema testing and preview deployments
  • Analytics: attach read replicas to offload heavy reporting workloads without copying storage
  • Disaster recovery: create branches from historical points-in-time for quick data inspection or restores

FAQ

Which connection method should I pick for serverless functions?

Use the serverless driver or HTTP/WebSocket options (e.g., @neondatabase/serverless) to avoid connection churn from short-lived invocations; enable pooling where possible.

When should I use Neon Auth vs the Neon JS SDK?

Use Neon Auth for managed authentication and UI flows; use Neon JS when you want a combined auth + typed data client with PostgREST-style querying.