Neon is the right Postgres for Vercel-hosted apps, indie projects that can tolerate cold starts, and CI/CD workflows that need per-PR database branches. It is not a replacement for Supabase if you need auth and storage bundled together, and it is not a reliable choice for production workloads with uptime SLAs unless you pay Scale plan rates. The year-one reliability story has dents in it — and you should know what they are before committing.

Who this is for

Indie developers and small teams picking a serverless Postgres for a side project, MVP, or Vercel-deployed app. Stop reading if your workload requires always-on connections with a sub-$25 monthly ceiling — you want Railway or Supabase Pro instead.

What we tested

We reviewed Neon’s Free and Launch plans in June 2026. Cold-start latency figures are from neon-latency-benchmarks.vercel.app, an open-source continuous benchmark maintained by Neon that probes all AWS regions every 15 minutes from Vercel serverless functions. The benchmark tests three connection methods: HTTP via the @neondatabase/serverless driver, WebSocket via NeonPool, and TCP via standard pg.Pool. Pricing figures are from official documentation as of June 2026. Branching workflow observations are based on the GitHub Actions integration docs and community reports.

Note: We did not run a live 48–72-hour billing test on a representative workload for this review. The billing example below is a worked calculation from published rates. Run your own test before making cost-based decisions — autoscaling can surprise you in either direction.

Neon cold-start latency

Neon databases auto-suspend after 5 minutes of inactivity. On the Free plan, this cannot be disabled.

The current latency picture (us-east-1, 0.25 CU compute, HTTP driver):

Metric	Value
Median cold start	~1.8s
P95 cold start	~2.6s
Worst observed	~3.1s
Hot query (simple SELECT, HTTP)	~2.1ms
Baseline comparison (late 2024)	~4–5s

The trajectory is good — cold starts have roughly halved since late 2024. The absolute number is still real: a 1.8-second cold start is visible to a user waiting on an API response.

The connection method matters more than most of the Neon marketing copy suggests. The HTTP serverless driver (@neondatabase/serverless) is consistently faster on cold starts than a TCP pg.Pool. For Vercel or Cloudflare Workers deployments, use the HTTP driver. TCP connections add overhead that the HTTP path skips entirely.

The range is wide by region and compute tier. Numbers from ap-southeast-1 or eu-central-1 will differ from us-east-1. Always check the live benchmark dashboard with your target region and connection method before drawing a conclusion — the difference between a 300ms P50 and a 2s P50 is real and matters for your architecture.

Autoscaling and billing reality

Current pricing (June 2026)

Free plan — no credit card, no expiry:

100 CU-hours/project/month (doubled from 50 in September 2025)
0.5 GB storage per project
Up to 100 projects
Autoscaling up to 2 CU (8 GB RAM)
Scale-to-zero after 5 minutes, cannot be disabled
10 branches per project

Launch plan:

$0.106/CU-hour compute (cut from $0.14 in November 2025)
$0.35/GB-month storage
Autoscaling up to 16 CU (64 GB RAM)
Scale-to-zero optional
No uptime SLA
10 included branches; extras at $1.50/branch-month up to 5,000

Scale plan:

$0.222/CU-hour compute
Autoscaling up to 16 CU (64 GB RAM); fixed compute up to 56 CU (224 GB RAM)
Scale-to-zero configurable from 1 minute to always-on
25 included branches
99.95% uptime SLA — this only applies here, not on Launch

Why prices dropped in November 2025

Databricks acquired Neon in May 2025. On November 3, 2025, Neon cut compute rates 15–25%, attributing it directly to AWS volume discounts gained through the acquisition. The Launch plan dropped from $0.14 to $0.106/CU-hour; Scale from $0.26 to $0.222. This was a real cut, not a restructuring.

Worked cost example

Low-traffic side project: autoscaling averages 0.25 CU, active 4 hours/day, 1 GB storage:

Compute: 0.25 CU × 4h × 30 days × $0.106 = $3.18
Storage: 1 GB × $0.35 = $0.35
Total: ~$3.53/month

For comparison: Supabase Pro is $25/month flat. Railway Postgres runs $5–10/month depending on usage. For genuinely low-traffic projects, Neon’s autoscaling-to-zero wins.

The risk: burst traffic keeps compute warm at a higher tier for longer than expected. A scheduled job, a deploy with heavy migrations, or a traffic spike can push a $3 month to $25. Pull your billing breakdown in the first few weeks.

New as of May 1, 2026: Snapshot billing at $0.09/GB-month. If you set up a project before May 2026, this is a new line item — check your bill. Manual snapshot limits also increased from 10 to 100 per project on paid plans (May 22, 2026).

Branching workflow in CI/CD

This is Neon’s real differentiator. The pricing is competitive but not unique. The branching is.

Neon’s branches use copy-on-write at the storage layer: creating a branch is an O(1) metadata operation. No data is copied, parent performance is unaffected, and the branch only stores deltas as writes diverge. This means branch-per-PR costs nothing until your feature branch writes diverge from main.

The GitHub Actions integration ships four actions that cover the full CI/CD workflow:

# On PR open: create a preview branch
- uses: neondatabase/create-branch-action@v6
  with:
    project_id: ${{ vars.NEON_PROJECT_ID }}
    branch_name: preview/${{ github.event.pull_request.number }}

# On PR close: delete the branch
- uses: neondatabase/delete-branch-action@v3
  with:
    project_id: ${{ vars.NEON_PROJECT_ID }}
    branch: preview/${{ github.event.pull_request.number }}

# In CI: show schema diff vs. main
- uses: neondatabase/schema-diff-action@v1
  with:
    project_id: ${{ vars.NEON_PROJECT_ID }}
    compare_branch: preview/${{ github.event.pull_request.number }}

# After main advances: sync the feature branch
- uses: neondatabase/reset-branch-action@v1
  with:
    project_id: ${{ vars.NEON_PROJECT_ID }}
    parent: true

The schema diff action surfaces schema drift in CI without additional tooling. That alone is worth evaluating Neon for any team that has been bitten by a surprise migration on deploy.

Where the friction is:

The native Vercel integration does not auto-delete branches when PRs close. Stale branches accumulate silently until you hit the branch limit. Wire up the delete action as a PR-close trigger or build a periodic cleanup step — it is not automatic.

Branch reset after migrations can fail if the feature branch has schema state that conflicts with what landed on main since the branch forked. It is not a common case, but it requires manual intervention when it happens.

Prisma requires explicit SSL configuration. Add ?sslmode=require to the connection string, or configure ssl: { rejectUnauthorized: false } in the Prisma client config. The docs cover it; first-time setup still catches people who skip the Neon-specific section.

Reliability and support

Read this section before committing to Neon for anything production.

The incident record

Neon’s outage history in 2025–2026:

Date	Region	Impact	Duration
May 16–19, 2025	us-east-1	DB creation and activation impossible	~5.5h total
May 8, 2026	us-east-1 Cell 6	~1,000 projects: slow/stuck compute starts	~2h
May 9–10, 2026	us-east-2	Elevated error rates, connectivity issues	~5h
May 25, 2026	sa-east-1	Compute operation failures	~1h 45m
June 1, 2026	us-east-1, eu-central-1	Branch/project creation failures	~1h

Four incidents in 90 days as of March 2026. tryorbye.com rates Neon reliability at 55/100, outage impact at 9/10 severity.

The pattern: every confirmed incident primarily affected scale-to-zero workloads and branch or project creation operations. Databases running with always-on compute have been largely unaffected. This distinction matters: if you are on the Scale plan with scale-to-zero disabled, your exposure to these incidents is materially lower.

The May 2025 root cause was detailed in a public postmortem: a PostgreSQL query planner picked a suboptimal index on an internal table, query times jumped from ~200ms to 100+ seconds, CPU saturation prevented the Activity Monitor from suspending idle VMs, the VM pool grew from ~6,000 to ~8,000, and two VPC subnets exhausted their IPv4 pool. New database creation and activation became impossible. Active, running databases were unaffected. The fix: reconfigured AWS CNI settings and doubled VPC subnet sizes. The long-term structural fix is the “Cells” architecture, which is in progress.

Gergely Orosz’s “3 outages in five days” criticism from the May 2025 period is accurate. When it comes up in comment threads, it is not exaggerated.

SLA reality

The 99.95% uptime SLA applies only to the Scale plan. The Launch plan has no SLA. This is not buried in the fine print — it is in the pricing page — but it is easy to miss when you are evaluating the product on cost. If you are running a production workload with any kind of external uptime commitment, you need Scale plan pricing.

Migration story

Neon supports all the standard migration paths:

Method	Best for	Downtime
Import Data Assistant	< 10 GB	Minimal
pg_dump / pg_restore	Any size	Some
pgcopydb	10 GB+ parallel migration	Some
Logical replication	Production, near-zero downtime	Near-zero

Migration is clean for standard Postgres applications. There are hard blockers to know before you start:

Hard blockers:

plv8 — rejected with an error as of 2025.
Custom C extensions — not installable.
track_commit_timestamp — not supported.

Behavioral surprises that will bite you if you are not expecting them:

pg_cron jobs are silently skipped during scale-to-zero suspension. pg_cron is supported on Neon at version 1.6 across PostgreSQL 14–17. But cron jobs only execute while compute is active. On scale-to-zero plans (Free, or Launch with scale-to-zero enabled), any job scheduled to fire while the database is suspended is missed — no retry, no error. If you depend on pg_cron for scheduled tasks, you need to either disable scale-to-zero (Scale plan) or move time-sensitive jobs to an external scheduler (Trigger.dev, Inngest, a cron endpoint hitting your API).
Unlogged tables are wiped on scale-to-zero, not only on abnormal shutdown. Standard Postgres only wipes unlogged tables after a crash. Neon wipes them on every suspension cycle. If any part of your app uses unlogged tables as a cache or temp store and expects them to survive restarts, that assumption is broken.
Session state (temp tables, prepared statements, LISTEN/NOTIFY subscriptions) is lost when idle connections are closed. Stateful connection patterns break.
No superuser access.
No pg_upgrade — major Postgres version upgrades require creating a new project and migrating data.

A typical Rails, Django, or Node.js app using standard ORM patterns migrates without code changes. An app that relies on unlogged tables or superuser access needs work before the migration. An app using pg_cron needs its job schedule evaluated against scale-to-zero suspension windows.

The Databricks acquisition

Databricks acquired Neon in May 2025 for approximately $1 billion. The community concern — that Neon gets absorbed into the Databricks enterprise stack, raises prices, or gets sunset — has not been formally addressed in either company’s public roadmap.

Evidence so far is neutral: prices dropped post-acquisition, the product roadmap is shipping, and the team appears intact. The uncertainty is real and unresolved. If you are building a production dependency on Neon, that is a factor worth weighing.

Verdict

Pick Neon if: You are building on Vercel or Cloudflare Workers, your CI/CD workflow would benefit from branch-per-PR databases, or you want a genuinely free tier with no credit card and no expiry. The branching experience is the best available at this price point.

Pick Supabase if: You need auth, storage, and realtime and want one monthly bill. Or if you need a production database with a better recent reliability record for a predictable $25/month.

Pick Railway if: You want the simplest possible setup — push a repo, get a Postgres, no cold starts, no configuration. Costs more than Neon for low-traffic projects but the experience is linear.

Do not pick Neon if: You need an uptime SLA without paying Scale plan rates, your app depends on pg_cron firing reliably while the database may be suspended (Free or Launch with scale-to-zero), or you have unlogged tables with data you cannot afford to lose on an idle cycle.

Caveats

First-hand billing tests and live cold-start measurements are not included in this review. Cold-start figures are from the community benchmark dashboard. Billing math is from published rates. Both should be verified against your actual workload before making a decision.

We have no affiliate relationship with Neon. Neon’s partner program is a technical integration program with no revenue share or referral commissions.

The Databricks acquisition risk assessment is a judgment call. The actual outcome depends on roadmap decisions neither company has publicly committed to.

Neon in 2026 — serverless Postgres one year in review