Neon alternatives: when the CU-hour meter stops matching the work

Short version: Neon is the best serverless Postgres you can buy, and its bill is shaped like the thing it sells: compute by the CU-hour, storage by the GB-month, branches by the branch-month past the included ten. That shape fits a production app with real traffic swings. It fights a stack of small databases that sit idle most of the day, and it fights a team that wants a branch per pull request without doing arithmetic first. Layerbase Cloud sells the other shape: Solo is $5/month, Pro is $15/month, and neither number moves when your traffic does. If your whole world is one busy Postgres, stay on Neon. If it is six quiet ones, read on.

What Neon actually is

Neon separated Postgres storage from compute and built a product around what that separation makes possible. Compute scales to zero when nobody is querying and wakes on the next connection. Storage is a copy-on-write log, so a branch of a 50 GB database is created in seconds and costs nothing until it diverges. The serverless driver speaks SQL over HTTP and WebSockets so edge runtimes that cannot hold a TCP socket can still run queries. Neon Auth bolts a managed identity layer onto the database. All of that is real engineering and it works as advertised.

The compute unit is the CU: 0.25 vCPU and 1 GB of RAM. A CU-hour is one of those for one hour. Autoscaling means a database can run at 0.25 CU during the night and 4 CU during a traffic spike, and the meter records whatever it was at each moment. That is the whole model, and it is elegant. It is also a meter, and a meter has to be modelled before you know what it costs.

The plan numbers

Verified 2026-09-06 from neon.com/docs/introduction/plans:

Free allows 100 projects, Scale allows 1,000 and more on request. Branches beyond the included count are billed per branch-month, which I will come back to.

The numbers above are the post-acquisition numbers, and they went down, not up. If you want the Databricks story, Neon is now a Databricks product has the long version. I am not going to restate it here, except to say that the product today is fine and the concern is the next eighteen months rather than the current price list.

Where the CU-hour meter bites

Nothing in the table is expensive. The bite comes from three shapes of workload that the meter handles badly.

Idle-heavy databases that cannot afford a cold start. On Launch, the fix for a five-minute scale-to-zero waking your API at 9am is to disable scale-to-zero. Now the compute runs 24 hours a day. At the 0.25 CU minimum that is 0.25 times 730 hours times $0.106, or about $19 a month per database, before storage, for a database that is awake and doing nothing. At 1 CU it is about $77. That is the price of "always on" in a model where always-on is the exception rather than the default.

Many small databases. A side project, its staging copy, a CI database, a scratch database for a migration you are nervous about. Each one is a project with its own compute meter. Each one either scales to zero and cold-starts, or stays warm and bills. The Free plan's 100 projects and 100 CU-hours per project genuinely cover a lot of this, and I will not pretend otherwise. The trouble is that 100 CU-hours at 0.25 CU is 400 hours of runtime, about 17 days, so a Free project with any steady traffic runs out mid-month and the compute suspends until the next billing period. Neon does not delete anything when that happens. It does stop answering.

Branches as a workflow rather than an occasional tool. Branching is Neon's best feature and the one they charge for most directly. Free and Launch include 10 branches per project, Scale includes 25, and Neon's plans page prices extra branches at $1.50 per branch-month, prorated hourly, as of 2026-09-06. A team that opens a branch per pull request and forgets to close them is paying for a habit. A branch that stays awake because a preview deployment keeps pinging it also pays for its own compute, on its own meter, separately from the parent.

None of this is a trick. Neon is honest about every line. The point is that you have to do the modelling, and that the answer changes with the shape of your stack rather than its size.

What Layerbase does differently

Flat plans with a floor of zero. Free is $0 with no card: 2 databases, 5 GB, 8 engines, sleeping after 15 idle minutes and waking on connect. Solo is $5/month for 2 databases with one of them always-on, 10 GB, and 3 branches per database. Pro is $15/month for up to 10 databases, 25 GB, all 18 engines on Layerbase Cloud, 10 branches per database, 30-day rolling backups, client-certificate auth on Postgres, and point-in-time restore on always-on Postgres. The scratch database and the CI database cost nothing extra because they fit in the plan you already bought.

Branches inside the plan. A branch on Layerbase is the same copy-on-write idea, and it is part of the per-database allowance rather than a per-month meter. Branching runs across 16 engines, not just Postgres, so the Redis next to your Postgres branches with it.

The same HTTP driver, no code change. Layerbase Postgres implements the Neon serverless HTTP protocol. @neondatabase/serverless, @vercel/postgres, Drizzle's neon-http adapter, and the Prisma and Kysely Neon adapters accept a Layerbase connection string as-is. The one gap is interactive transactions over WebSocket; sql.transaction() batches work, and the standard pg client covers everything else.

Publicly reachable TLS endpoints. Every database has a hostname anything can connect to: CI, a teammate's SQL client, a job on another host. If you want the stricter posture, Postgres on Pro supports client certificates with a per-database CA.

One account for the rest of the stack. Neon is Postgres and only Postgres. On Layerbase, the cache, the search index, and the analytics store are a dropdown on the same dashboard rather than three more vendors.

Stay on Neon if

I would not move a database off Neon reflexively. These are the cases where staying is clearly right.

• Your bill runs through Vercel and you want it to stay there. The Marketplace integration is the tightest one Vercel has, and one invoice is worth something. Neon vs Supabase covers the Vercel angle in more depth.
• Your production traffic is genuinely bursty. If your database needs 4 CU at noon and 0.25 CU at midnight, autoscaling is exactly the thing you want and a flat plan cannot give it to you. A pool that is sized for the peak is what we sell, and for a spiky enough workload the meter wins.
• You use Neon Auth. It is managed Better Auth, and the users, sessions, and password hashes live in a neon_auth schema inside your database, so a pg_dump carries them. What does not come across is the managed service around that schema: the hosted endpoints, the console, the upkeep. Leaving means running Better Auth yourself against the same tables, which is real work, and if Neon Auth is the reason you are there, that is a reason to stay.
• You want the most mature Postgres branching on the market. Neon has been doing this longer than anyone, with schema diffs, restore-to-timestamp on branches, and a branch API that every CI system already has an example for.
• You need read replicas. Neon has them. We do not.

The case for moving is narrower and specific: you have more databases than production databases, most of them are idle, the branch count keeps drifting up, or you want the second engine on the same bill.

The move, with real commands

The app does not move. Only the connection string changes.

1. Copy the data. The Neon migration page runs the guided path: paste a Neon API key, it lists your projects, branches, and databases, and it copies the one you pick in a single read-once pass through the direct endpoint. Nothing is written to your Neon project, and the key is not stored. If you only have a pooled connection string, paste it anyway. We switch -pooler hosts to the direct endpoint before copying.

Or do it by hand, which is the same two commands it has always been:

pg_dump "postgresql://neondb_owner:<password>@ep-xxxx.us-east-2.aws.neon.tech/neondb?sslmode=require" \
  --no-owner --no-acl \
  | psql "postgresql://layerbase:<password>@<host>.cloud.layerbase.dev:5432/appdb?sslmode=require"

Use the direct hostname, not the -pooler one. A transaction pooler and a long pg_dump do not get along.

2. Point the app at the new database. For a Vercel project:

vercel env rm DATABASE_URL production
vercel env add DATABASE_URL production
# paste the Layerbase string
vercel --prod

If the app uses the Neon serverless driver, that is the whole change. The import stays the same.

3. Verify before you delete anything. Row counts on both sides, then run the app against the new database for a few days. Neon storage bills on what is stored, so the old project keeps charging until it is gone, but a week of insurance is cheap. Migrating from Neon to Layerbase has the step-by-step version with the gotchas we have hit.

FAQ

How much does Neon cost?

As of 2026-09-06, Free is $0 with 100 CU-hours and 0.5 GB per project, Launch is pay-as-you-go at $0.106 per CU-hour and $0.35 per GB-month, and Scale is $0.222 per CU-hour with the same storage rate. Free and Launch include 10 branches per project, Scale includes 25, and branches beyond that are billed per branch-month. There is no monthly minimum on the paid plans.

Does Neon scale to zero, and can I turn it off?

Yes, after 5 minutes of inactivity by default. On Free it cannot be disabled. On Launch it can be turned off, and on Scale the timeout is configurable from 1 minute up to always on. Disabling it means the compute bills for every hour of the month, which is where an idle database becomes a $19-and-up line item.

Do I have to rewrite my code to leave Neon?

Almost never. Layerbase Postgres speaks the same HTTP protocol as the Neon serverless driver, so @neondatabase/serverless, @vercel/postgres, and Drizzle neon-http work against a Layerbase connection string without changes. Standard TCP drivers work too. The only gap is interactive transactions over WebSocket, which the plain pg client covers.

What happens to Neon Auth users?

The data does. Neon Auth is managed Better Auth, and it keeps users, sessions, and password hashes in a neon_auth schema in your database, so those tables come across with everything else and nobody needs a password reset. What you lose is the managed service in front of them. Plan to self-host Better Auth against that schema before you cut over, or count Neon Auth as a reason to stay.

Is a $15 flat plan really comparable to Neon?

Not feature for feature. Neon has autoscaling compute, read replicas, and the deepest branching toolset in the business. Pro is $15/month for up to 10 databases, 25 GB, branching, 30-day backups, and no meter. If you need one database that scales with traffic, Neon's number is buying you something. If you need six databases that mostly sleep, the flat number is the one that decides it.

Is Neon still safe to use after the Databricks acquisition?

Yes. Prices went down after the deal closed and the product has not changed for the worse. The reason to hedge is strategic rather than technical, and the Databricks post makes that case without overstating it.

The wrap-up

Neon built serverless Postgres properly, and priced it the way serverless things get priced: for what you use, by the hour, by the branch. That is the right model for a busy application and the wrong one for a shelf of quiet databases and a branch-per-PR habit.

If your stack is one production Postgres with real traffic swings, stay. If the database count keeps growing and most of them are idle, start at the Neon migration page, or create an empty Postgres and point the driver you already have at it.