Neon review: serverless Postgres with branching, and what it costs

Q: Can I move an existing Postgres database to Neon?

Yes. Since Neon is standard Postgres, a standard pg_dump and pg_restore , or Neon's own import tooling, moves an existing database over without a compatibility layer to work around.

Filed under Review

By Gerald · 16 August 2026

A close-up of a server rack lit in green, representing the compute and storage layer a serverless Postgres database runs on

Neon is the best fit for preview environments and low-traffic apps that want real Postgres without managing a server, and it is a poor fit if you need predictable single-digit-millisecond latency around the clock. Database branching is the genuine differentiator, and it holds up in practice. Cold starts on the free tier are the tradeoff you are actually signing up for.

I picked Convex for Flow's own backend, but I have run Neon on smaller side projects specifically to test branching against a real migration workflow, not just the demo. This review covers what held up, what did not, and current pricing as shown on Neon's own pricing page in August 2026.

Branching is not a gimmick. It genuinely changes how you test a schema migration. Just do not confuse "scales to zero" with "scales predictably," because those are different promises.

What Neon is and who it is competing with

Neon is standard PostgreSQL, not a Postgres-compatible reimplementation, running on a storage architecture that separates compute from storage so compute can suspend independently. That separation is what makes both branching and scale-to-zero possible: a branch is a cheap copy-on-write pointer into the same storage layer, not a full physical copy of your database.

It competes most directly with Supabase, which I have also used and reviewed. It increasingly competes with Convex too, on the "backend that gets out of your way" pitch, though Convex is a different kind of product: a reactive document database with built-in functions, not raw SQL. If your app needs standard Postgres tooling and an ORM like Prisma or Drizzle without a translation layer, Neon and Supabase are the two to actually compare. Want live-updating queries without hand-building a sync layer instead? That is covered in my Convex review.

Neon was acquired by Databricks in a roughly $1 billion deal announced in May 2025. The deal has since closed. Neon's own messaging says the product and roadmap continue independently, with deeper integration into the Databricks ecosystem over time. For an independent developer, the practical read cuts two ways: it lowers the risk of Neon disappearing, and it raises the risk of the product drifting toward enterprise data-platform features rather than staying focused on solo and small-team use. Neither has clearly happened yet.

Database branching, and whether it changes how you work

Bare tree branches forking against a plain sky, representing database branches splitting off from a single parent — A Neon branch works like a Git branch: cheap to create, meant to be short-lived.

Creating a branch takes seconds and gives you a full, independently writable copy of your database's current state, including data, not just schema. In practice, that means you can open a pull request, spin up a Neon branch tied to that PR, run your migration against it, and throw it away when the PR merges or closes, without touching your production database at any point.

I tested this specifically against a real migration, not the sample data from Neon's own demo. A branch created from a database with a few hundred thousand rows was usable within seconds, and running an actual column rename and backfill against it behaved identically to running it against the parent, which is exactly what you want from a staging environment: a faithful copy, not a toy.

The place branching gets less magical is when you want branches to diverge for a long time. Branches are copy-on-write against the parent's storage, so a short-lived preview branch is nearly free, but a long-lived development branch that accumulates its own significant writes starts accumulating its own storage cost too. Branching is built for short-lived, disposable use, not as a permanent parallel environment.

Cold starts and scale to zero

This is the part every Neon review mentions and few quantify. On the free tier, scale-to-zero is always on and cannot be disabled: compute suspends after five minutes of inactivity, per Neon's own pricing page. The first query after that idle period pays a cold-start cost, which independent benchmarking in 2026 generally puts in the 500 millisecond to two second range depending on compute size, a meaningful improvement over older serverless Postgres cold starts but still a real, felt delay on the first request.

For a background job, a cron task, or a CI pipeline, that delay is invisible, since nothing is waiting on it in real time. For a user-facing web request that happens to be the first one after a quiet period, it is not invisible. It shows up as one slow page load, and if your app has bursty, unpredictable traffic rather than a steady stream, you will see this more often than a demo video suggests.

On paid tiers, the idle timeout before suspension is configurable from five minutes up to seven days, or scale-to-zero can be disabled entirely if you would rather pay for always-on compute and never see a cold start again. That configurability is the honest fix: free-tier cold starts are a real limitation, and paid-tier cold starts are a choice you get to make deliberately.

What the pricing model actually charges you for

Neon's 2026 pricing dropped substantially from what older reviews describe, following the Databricks acquisition, so any number from a review before mid-2025 should be treated as stale. As shown on Neon's pricing page in August 2026: storage is $0.35 per GB-month on the Launch and Scale plans, and compute is billed per CU-hour, at $0.106 per CU-hour on Launch and $0.222 per CU-hour on Scale. The free tier includes 100 CU-hours and 0.5 GB of storage per project, with no separate compute charge within that allowance.

The number that catches people is CU-hours, not gigabytes. A CU-hour scales with both how much compute you provision and how long it actually runs, so a database that is queried constantly during business hours burns through its allowance very differently from one that is genuinely idle most of the day, even if both store the same amount of data. If you are budgeting, model your actual query pattern against CU-hours, not just your expected storage size, because storage is rarely where a Neon bill goes over budget. Compute time is.

Where Neon frustrated me

Two things stood out as real friction, not nitpicks. First, cold starts on the free tier are non-negotiable, and if you are prototyping something you plan to demo live to someone else, that first-request delay is an avoidable bad first impression you have to actively work around, either by pinging the database beforehand or upgrading to a tier where you can extend the idle timeout.

Second, branching's cost model is easy to misjudge if you treat every feature branch like a free lunch. It is nearly free for short-lived branches and gets meaningfully less free the longer a branch lives and diverges, and the pricing page does not make that curve obvious at a glance. Treat branches the way you treat feature branches in Git: create them freely, but merge or delete them promptly rather than letting a dozen stale ones accumulate.

Who should use Neon and who should not

Neon is a strong choice if you want real Postgres, you like the idea of disposable per-PR database branches, and your traffic is either low-volume, internal, or has predictable warm periods where cold starts do not bite. It is also a reasonable pick if you are already inside or adjacent to the Databricks ecosystem, since that integration is only going to get deeper.

It is a weaker choice if your app serves latency-sensitive traffic at unpredictable hours and you are not willing to pay for always-on compute to avoid cold starts, or if branching is not a workflow you will actually use, in which case you are paying attention to a feature that will not change how you build. My Supabase review and Supabase alternatives worth a look cover the closest direct comparison if branching specifically is not the deciding factor for you.

Frequently asked questions

Is Neon real Postgres or a Postgres-compatible database? Real Postgres. Neon runs standard PostgreSQL with a custom storage layer underneath that separates compute from storage to enable branching and scale-to-zero. Existing Postgres tooling, extensions, and drivers work as expected.

How slow is a Neon cold start after scale to zero? Independent 2026 benchmarks generally show 500 milliseconds to two seconds for the first query after an idle suspension, depending on compute size. It is a real, noticeable delay for a user-facing request, though invisible for background jobs and CI pipelines that are not time-sensitive.

Is Neon cheaper than Supabase? It depends on your usage pattern, since the two price different things: Neon charges separately for storage and CU-hours of compute, while Supabase bundles compute into its plan tiers with its own storage add-on pricing. Check both current pricing pages against your actual expected traffic rather than assuming either is cheaper by default.

Can I move an existing Postgres database to Neon? Yes. Since Neon is standard Postgres, a standard pg_dump and pg_restore, or Neon's own import tooling, moves an existing database over without a compatibility layer to work around.

Does Neon work with Prisma and Drizzle? Yes, both work against Neon the same way they work against any standard Postgres connection string, with no special adapter required for basic use, though Neon does offer an optional serverless driver for edge runtimes where a normal TCP connection is not available.

My verdict

Neon delivers on branching, and the pricing is genuinely competitive after the 2026 cuts. Use it for previews and low-traffic apps without hesitation. Pay for always-on compute, or accept the cold start, before you put it behind unpredictable production traffic.