Neon serverless PostgreSQL

Neon is a serverless PostgreSQL platform: compute and storage are separated, compute autoscales and can scale to zero when idle, and copy-on-write storage makes database branches cheap enough to create one per pull request. It runs community PostgreSQL — recent majors including 17 and 18 are available as of this check — so drivers, SQL, and most extensions behave as expected. For positioning against other platforms, see the cloud service map.

What Neon changes

• Database branching as a first-class workflow. A branch is a copy-on-write clone of data and schema, created in seconds. Preview environments, CI runs, and migration rehearsal can each get a full database without duplicating storage cost.
• Scale-to-zero and autoscaling. Idle computes suspend automatically and resume on the next connection; busy computes scale within a configured range. Intermittent workloads stop paying for idle capacity.
• Pooled and direct endpoints. Neon exposes a PgBouncer-based pooled connection string alongside a direct one; they have different purposes and different limits.
• Usage-based billing. Compute is metered in CU-hours and storage in GB-months, so cost modeling differs from per-instance services; check the pricing page with a realistic traffic pattern.

Database branching workflow

The current Neon CLI is installed as neon (neonctl remains an alias), checked on 2026-08-06:

npm install -g neon
neon auth
neon projects create --name myapp
neon branches create --name feature/x --parent main
neon connection-string feature/x

A typical branch-per-feature cycle:

export DATABASE_URL=$(neon connection-string feature/x)
psql "$DATABASE_URL" -c "ALTER TABLE users ADD COLUMN beta_flag boolean DEFAULT false;"

# branches do not merge automatically — apply the reviewed SQL to main yourself
psql "$(neon connection-string main)" -f migrations/0042_add_beta_flag.sql

# compare schemas before merging
neon branches schema-diff main feature/x

neon branches delete feature/x

The important discipline is the middle step: a Neon branch copies data and schema at creation, but there is no automatic schema merge back. Migrations still go through your normal review and migration tooling, applied to main like any other change.

Differences to accept

• Cold starts after suspend. With scale-to-zero enabled, the first connection after an idle period waits for compute to resume. Tune the suspend timeout, or disable it, for latency-sensitive production services — and test how your driver and pooler retry during a wake-up.
• A project's region is fixed at creation. Deployment is in one AWS region per project (Azure regions are being phased out), and you cannot move a project between regions later — migration means a new project plus data movement. Check the current region list.
• Extensions come from an allowlist. Extensions needing OS-level access or arbitrary shared libraries are not available; confirm the exact list and versions in the extension documentation.
• Branch data governance is on you. A branch copies production data by default. If branches reach CI or preview environments, plan masking or branch from an anonymized parent.

Validate before production

1. Measure cold-start latency with your actual driver, ORM, and connection pooler after a real idle period.
2. Decide pooled versus direct connections per workload, and test prepared statements and transaction-pooling behavior on the pooled endpoint.
3. Define branch lifecycle and data-masking rules before branches reach shared environments.
4. Exercise branch-based restore inside your plan's restore window, and export once with pg_dump into an independent PostgreSQL.
5. Model CU-hour and storage consumption from a realistic traffic week, not from the free-tier shape.

For pooling, backup drills, and monitoring that apply on any provider, see the production stack guide.