Keep Neon-style branching, drop the compute meter

Short version: nobody chooses Neon for the CU-hour. They choose it because a copy-on-write branch of a real database, in seconds, changes how a team works, and then the meter is the price of admission. This post is for the person who wants to keep the workflow and stop paying per branch, per hour, per project. Layerbase branches the same way, as a copy-on-write fork with its own connection string, and the branches live inside a plan that costs $5 or $15 a month whether they are awake or not. The driver you already use keeps working. What you give up is real and listed at the end.

Contents

• What a branch costs on a meter
• The same workflow inside a flat plan
• Preview per pull request, without the arithmetic
• The driver does not change
• What Neon still does better
• The move
• FAQ

What a branch costs on a meter

Neon's branch is genuinely good. Storage is a copy-on-write log, so a branch of a large database is created in seconds and shares pages with its parent until they diverge. That part is free in the physics sense, and Neon is honest that it charges for what surrounds it rather than the branch itself.

Three lines on the bill are where a branch-per-PR habit shows up. All of these are from Neon's plans page, verified 2026-09-06:

• Included branches are per project. Free and Launch include 10, Scale includes 25. A team that opens a branch per pull request and merges eight PRs a week is past ten in under two weeks unless something is closing them.
• Extra branches are $1.50 per branch-month, prorated hourly. Cheap on its own. The cost is the bookkeeping: somebody has to own closing branches, and the ones nobody remembers are the ones that bill.
• Every branch has its own compute meter. This is the one that surprises people. A preview deployment that keeps a health check pinging its branch keeps that branch's compute awake, and it bills on its own CU-hours, separately from the parent. On Launch that is $0.106 per CU-hour, so a branch pinned awake at the 0.25 CU minimum is about $19 a month by itself, before anything else runs.

None of this is a trick, and Neon documents every line. The shape of the problem is that the bill moves with behavior that is hard to see from a pricing page: how many branches are open right now, and how many of them something is keeping warm. That is the arithmetic. I wrote the broader version of it, with the plan table and the idle-database math, in Neon alternatives: when the CU-hour meter stops matching the work. This post is the narrower case: you specifically want branching, and the meter is the only reason you are looking.

The same workflow inside a flat plan

A Layerbase branch is a fork of the database into a new database with its own host, port, and credentials. Writes on the branch never reach the parent, and writes on the parent never reach the branch. Branches form a tree, so you can branch a branch, and every database page shows its lineage.

Turn on Branching under a database's Settings and the fork becomes a copy-on-write clone on the server: a new branch appears in a second or two regardless of size, shares data with its parent until the two diverge, and makes no full copy up front. That is the same idea Neon built on, moved down to the filesystem, which is why it works on 16 engines rather than Postgres alone. The Redis next to your Postgres branches with it.

What changes is where the branch sits on the bill. Solo is $5/month and Pro is $15/month, and neither number moves because a branch is open or something is pinging it:

A branch counts as a database for storage and draws on the plan's limits like any other, so a large tree is not free in disk terms. It is free in the sense that matters here: no line on the invoice changes because a branch was open, or because something was pinging it.

Two lifecycle details make this workable rather than just cheap. A branch labeled Preview or Development is treated as ephemeral: it hibernates after 20 idle minutes and wakes on the next connection in about 1 to 5 seconds, which is what you want for a preview nobody has clicked in an hour. And Reset from parent re-forks a branch from the parent's current data while keeping the branch's host, port, and credentials, so a connection string you already wired into a preview environment keeps working after the reset. Only the data is replaced. The full mechanics, including what the confirmation dialog warns you about before a destructive reset, are in the branching guide.

Preview per pull request, without the arithmetic

The workflow people actually want from Neon is a database branch per preview deployment. The Vercel integration does that: your production git branch points at the main database, and preview deployments run against a copy-on-write branch with the connection string injected for you. By default every preview shares one staging branch forked from production. A mapping can instead use its own isolated preview branch, or per-branch mode, where each git branch gets a database branch of its own, which is the Neon shape. Reset staging on every deploy turns the staging branch back into a clean copy of production before each preview builds.

The GitHub integration covers the other half of the flow without Vercel in the middle: it maps a staging git branch to a staging database branch and, if you opt in, re-forks that branch from production every time a pull request merges into your base branch, so staging never drifts.

The thing to notice is what is missing from that description: there is no step where you estimate how many PRs will be open this month or which previews will keep their branch warm. On a meter, a preview that a stakeholder leaves open in a tab is a branch that is billing compute. Here it is a database that went to sleep. The longer treatment of why shared preview databases sabotage each other, and how the branch fixes it, is a database branch for every Vercel preview.

The driver does not 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, so the code that runs against a Neon branch runs against a Layerbase branch after an environment variable changes. The standard pg client works too, over plain TCP with TLS.

The one gap is interactive transactions over WebSocket. sql.transaction() batches work, and if you need a real interactive transaction from an edge runtime, that is a case for the TCP driver. Postgres over HTTP goes through exactly what the protocol covers and what it does not.

What Neon still does better

I would rather you stay on Neon than move and be disappointed, so this is the list I would show a friend.

• Branch tooling depth. Neon has been doing this longer than anyone. Schema diff between branches, restore a branch to a timestamp, and a branch API that every CI system already has a worked example for. Ours is create, reset from parent, and delete, with lineage on the page. If your pipeline leans on schema diff, that is a reason to stay.
• Autoscaling compute. If your production database needs 4 CU at noon and 0.25 CU at midnight, the meter is buying you something a flat pool cannot. Flat plans are sized for the peak.
• Read replicas. Neon has them. We do not.
• Neon Auth. The neon_auth schema comes across in a pg_dump, but the managed service in front of it does not. Leaving means self-hosting Better Auth against those tables, which is real work.
• The Vercel Marketplace bill. If one invoice through Vercel is worth something to your finance person, it is worth something.

The case for moving is specific: branching is your workflow, most branches are idle most of the time, the open-branch count drifts up, and you would rather the bill did not depend on either.

The move

The app does not move. The connection string does.

1. Copy the data. The Neon migration page takes a Neon API key, lists your projects and branches, and copies the one you pick through the direct endpoint in a single read-once pass. Nothing is written to Neon and the key is not stored. Or do it by hand:

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.

2. Turn on Branching for the new database under its Settings tab, once, so every branch after that is a copy-on-write clone rather than a full copy. For Postgres on the shared port the connection string does not change when you do this.

3. Point the previews at branches. Install the Vercel or GitHub integration, map the project, and pick reset-on-deploy if you want each preview to start from clean production data.

4. Swap the environment variable and verify before you delete anything on the Neon side. Neon storage bills on what is stored, so the old project keeps charging until it is gone, but a week of overlap is cheap insurance. Migrating from Neon to Layerbase has the gotchas we have hit.

Free is $0 with no card, 2 databases and 5 GB, and branching is available on it, so you can run the import and open a branch before you decide anything.

FAQ

Does Layerbase branching work the same way as Neon branching?

The mechanism is the same idea: a copy-on-write fork that shares data with its parent until the two diverge, created in a second or two regardless of size once Branching is enabled on the database. The branch gets its own host, port, and credentials, and Reset from parent re-forks it while keeping that connection string. What Neon adds on top is deeper tooling: schema diff, restore-to-timestamp on a branch, and a more mature branch API.

How many branches do I get?

Free allows 1 branch per database, Solo allows 3, and Pro allows 10. There is no per-branch charge and no branch-month. A branch counts as a database for storage, so a large tree draws on the plan's storage limit like any other database would.

What does an idle branch cost?

Nothing beyond the plan. A branch labeled Preview or Development hibernates after 20 idle minutes and wakes on the next connection in about 1 to 5 seconds. On a meter, an idle branch either scales to zero and cold-starts or stays warm and bills its own compute; here the sleeping and the waking are both free.

Can I keep using the Neon serverless driver?

Yes. Layerbase Postgres speaks the Neon serverless HTTP protocol, so @neondatabase/serverless, @vercel/postgres, and Drizzle's neon-http adapter work against a Layerbase connection string without changes. The only gap is interactive transactions over WebSocket, which the plain pg client covers.

Can I branch something other than Postgres?

Yes. Branching runs on 16 engines in Layerbase Cloud, including MySQL, MariaDB, Redis, Valkey, FerretDB, ClickHouse, Qdrant, and QuestDB, because it happens at the filesystem rather than inside the engine. CouchDB and TigerBeetle are excluded by design because they keep cluster identity inside their data.

When should I stay on Neon?

When your pipeline depends on schema diff or restore-to-timestamp on branches, when your production traffic is bursty enough that autoscaling compute is saving you money, when you need read replicas, or when Neon Auth is the reason you are there. Those are real features and a flat plan does not replace them.