Neon: Serverless Postgres That Branches Like Git

If you have ever wanted a Postgres database that spins up instantly, costs nothing when idle, and lets you branch your entire dataset for testing — Neon is built specifically for that workflow.

Photo by Siamak on Unsplash

What Neon Actually Is

Neon is a managed Postgres service, but the architecture underneath is fundamentally different from RDS or Supabase's Postgres. The key idea is separation of storage and compute. Your data lives in a custom storage layer (based on a pageserver that writes to S3-compatible object storage), while compute nodes are stateless Postgres instances that can start and stop independently.

This separation enables two things that traditional Postgres hosting cannot do cheaply:

1. Scale to zero — when nobody is querying the database, the compute shuts down entirely. You pay only for storage. When the next query arrives, a compute node starts in about 500ms.

2. Instant branching — creating a branch is a copy-on-write operation at the storage layer, not a full pg_dump. A 50 GB production database branches in under a second.

Branching Is the Killer Feature

Database branching sounds like a nice-to-have until you actually use it in a real workflow. Here is what it enables:

Preview environments: Your CI pipeline creates a Neon branch for every pull request. The branch has a full copy of your production schema and seed data. Your integration tests and preview deploy run against it. When the PR merges, the branch is deleted. No shared staging database. No test data collisions.

# In your CI pipeline
neonctl branches create --name "pr-${PR_NUMBER}" --parent main

# Get the connection string
DATABASE_URL=$(neonctl connection-string "pr-${PR_NUMBER}")

# Run migrations and tests against the branch
DATABASE_URL=$DATABASE_URL npx prisma migrate deploy
DATABASE_URL=$DATABASE_URL npm test

# Cleanup
neonctl branches delete "pr-${PR_NUMBER}"

Safe migration testing: Before running a migration on production, branch off production and run the migration on the branch. If the migration takes 45 minutes on a branch with real data, you know it will take roughly the same on production — and you did not touch production to find out.

Point-in-time recovery: Neon keeps a history of your data (configurable retention, 7 days on the free tier). You can branch from any point in that history. Accidentally deleted a table at 3:47 PM? Branch from 3:46 PM and recover the data.

The Serverless Driver

Neon ships a JavaScript driver (@neondatabase/serverless) that works over WebSockets and HTTP. This matters for edge runtimes like Cloudflare Workers, Vercel Edge Functions, and Deno Deploy — environments where raw TCP sockets are not available.

import { neon } from "@neondatabase/serverless";

const sql = neon(process.env.DATABASE_URL);

const posts = await sql`SELECT * FROM posts WHERE published = true ORDER BY created_at DESC LIMIT 10`;

The driver also works with connection pooling through Neon's built-in proxy, so you do not need to set up PgBouncer separately. For traditional Node.js or server environments, you can use the standard pg driver — Neon is just Postgres, so any Postgres client works.

What the Free Tier Gets You

Neon's free tier is genuinely usable for small projects and prototyping:

• 0.5 GB of storage
• 190 compute hours per month (the default 0.25 CU size means this goes far)
• Branching included
• Scale-to-zero enabled by default
• One project with up to 10 branches

For a side project or early-stage SaaS, that is enough to run for months before hitting limits. The paid tiers start at $19/month and add more storage, compute, and longer history retention.

How It Compares

vs. Supabase Postgres: Supabase bundles auth, storage, edge functions, and real-time into a platform. Neon is focused purely on being the best serverless Postgres. If you want a database and will bring your own auth and API layer, Neon is more focused. If you want a Firebase-like platform, Supabase gives you more out of the box.

vs. PlanetScale: PlanetScale also does branching, but it uses Vitess (MySQL-compatible), not Postgres. If your stack is Postgres-native (Prisma, Drizzle, Django, Rails), Neon is a more natural fit. PlanetScale also removed their free tier in 2024, while Neon's is still available.

vs. RDS / Cloud SQL: Traditional managed Postgres does not scale to zero and does not branch. You pay for an always-on instance even when nobody is using it. For production workloads with consistent traffic, RDS can be more cost-effective at scale. For variable workloads and dev/test environments, Neon wins on cost.

vs. Turso (libSQL/SQLite): Turso uses SQLite at the edge — embedded, replicated, ultra-low-latency reads. Neon is full Postgres — richer query capabilities, more ecosystem tooling, but higher per-query latency. If you need joins, complex queries, and full SQL, Neon. If you need sub-millisecond reads at the edge, Turso.

Practical Tips

Connection pooling matters: Serverless functions can create many short-lived connections. Use Neon's built-in connection pooling (add -pooler to your host) or the serverless driver, which handles this automatically.

Set a reasonable auto-suspend timeout: The default is 5 minutes of inactivity before compute suspends. For development databases, this is fine. For production, you might want to increase it or disable auto-suspend to avoid cold start latency on the first query after idle.

Use branches for schema changes: Instead of running ALTER TABLE directly on production, create a branch, apply the change, verify it works, then apply to production. This is especially valuable for changes that lock tables — you can estimate lock duration on the branch without impacting users.

Watch your storage: Branching is cheap in compute but branches do consume storage as they diverge from the parent. Clean up branches you are done with, especially in CI pipelines.

When to Choose Neon

Neon makes the most sense when:

• You want Postgres but do not want to pay for an always-on instance
• Your workflow benefits from database branching (preview environments, safe migrations)
• You are deploying to edge runtimes that need HTTP-based database access
• You want to start free and scale up as your project grows

If your database runs at consistent high load 24/7 and you never need branching, traditional managed Postgres is probably simpler and potentially cheaper at scale. But for the increasingly common pattern of serverless applications with variable traffic, Neon is one of the strongest options available.