Netlify DB alternatives: your database should outlive your deploy platform

Short version: Netlify DB is Neon Postgres that Netlify operates and resells. It went GA on April 28, 2026. It is billed out of the same credit balance that pays for your builds and your bandwidth, which makes your database bill a function of how your site's traffic behaved that month. The provisioning experience is genuinely excellent and the per-preview branches are the best part of it. If what you want is a database with a price you can say out loud, the move is one connection string and one redeploy, and the site never leaves Netlify.

I like Netlify. I have shipped things on it, the deploy story is still one of the cleanest in the business, and none of what follows is an argument to move your site. The site can stay.

The database is a different question, and it is worth asking separately, because the thing that makes Netlify DB pleasant to start is the same thing that makes it awkward to reason about later.

What Netlify DB actually is

It is Neon, operated and resold by Netlify. That is not a criticism. It is a good decision. Netlify did not build a Postgres, they wired up one that already works and put a provisioning button in front of it.

The dates, verified 2026-08-28 against Netlify's changelog and the Netlify database docs:

• The beta was frozen on April 13, 2026. No new beta databases after that.
• General availability landed April 28, 2026.
• Neon described the partnership from their own side when it launched, in their post on Netlify DB.
• During the beta, a database could be claimed into your own personal Neon account. The GA documentation does not describe a claiming step.

That last bullet is the one I would put on a sticky note. I am stating what the docs say and do not say, not accusing anyone of removing an escape hatch. But "the beta had a documented path into your own Neon account, and the GA product does not describe one" is a meaningful difference in posture, and it is the kind of thing that is much easier to notice now than during an incident.

The coupling problem

Here is the actual shape of the concern, and it has nothing to do with Neon's quality.

Your database lives inside your deploy platform's account, on your deploy platform's billing model, subject to your deploy platform's plan changes. Three things that used to be independent are now one thing. Your CI minutes, your bandwidth, and your production data all draw from the same balance and the same vendor relationship.

Most of the time this is invisible and fine. It stops being invisible in exactly the situations where you would rather have fewer variables:

• You want to move the frontend to another host. Now that is a frontend migration and a database migration, because the database was never really a separate thing.
• Something outside Netlify needs the same data. A worker on a VPS, an analytics job, a colleague with a SQL client, a second app.
• Billing changes. Every platform reprices eventually. When your database is a line item in your host's plan, their pricing decision is your database's pricing decision.

None of these are hypothetical crises. They are just Tuesdays that cost more than they should when the database is a feature of the host rather than a thing you own.

Where the credits get you

Netlify DB is on credit-based plans. An active database burns credits for compute and for bandwidth. Storage was free until July 1, 2026 and has been billed since.

Netlify has not published a per-GB storage rate, so I am not going to quote one. That is a real gap and worth saying plainly: as of 2026-08-28 I could not find a published per-GB figure in Netlify's pricing documentation, which means the honest answer to "what will 20 GB cost me" is that you find out from your invoice.

The credit model has a subtler property that matters more than the rate anyway. Compute and bandwidth are both driven by traffic. So your database bill is a function of your traffic shape, not of your data. Two sites with identical schemas and identical row counts get different database bills because one of them got posted to Hacker News. That is fine if your revenue moves with your traffic. It is annoying if you are running a side project, a docs site, or an internal tool, where a good traffic day produces zero dollars of revenue and a nonzero database charge.

The thing people actually dislike about metered pricing is rarely the amount. It is that you cannot answer "what does this cost per month" without qualifications.

What Netlify genuinely got right

I want to be specific here, because a comparison post that cannot name the competitor's wins is marketing rather than analysis.

Zero-setup provisioning is excellent. You do not pick a region, a plan, an instance size, or a Postgres version. You get a database. For a huge number of projects that is the correct default, and every host that makes you fill out a form before you can write a row should look at it.

The per-deploy-preview branches are the best feature in the product. Every deploy preview gets its own database branch automatically, with no wiring on your part. Preview environments that share a database are a well known source of "who deleted the test data" and Netlify made that problem disappear without asking you to think about it. That is a genuinely good piece of platform engineering, and it is the feature I would miss.

The SDK does the boring part. @netlify/database exposes getDatabase(), which resolves its own connection in the Netlify environment, and getDatabase({ connectionString }) when you want to hand it an explicit one. That second signature is more important than it looks, and I will come back to it.

What Layerbase does differently

Three things, and they are all consequences of the database not being part of a deploy platform.

Flat pricing. Free is $0 with no card: 2 databases, 5 GB. Solo is $5/month. Pro is $15/month. No compute meter, no bandwidth meter on the database, no per-row anything. A traffic spike does not change the number. You know the bill on the first of the month, which is the entire point.

Branching that is not tied to a host. Instant branches are a Layerbase feature, available on all three plans and supported on 16 of our engines. They work the same whether your app deploys to Netlify, Vercel, Cloudflare, a Hetzner box, or nothing at all. You do not get the automatic per-preview wiring for free the way Netlify does, which is a real trade, and you also do not lose branching the day you change hosts.

18 engines on one account. Postgres is where most people start, and then the stack drifts: a cache, a vector store, a search index, something for time-series metrics. On Layerbase Cloud the second engine is a dropdown and the same bill, not a second vendor and a second invoice.

Backups come with it: a manual slot on Free, 7-day rolling daily backups on Solo, 30-day rolling on Pro. Point-in-time recovery is available on Pro and above, and it requires the database to be pinned always-on, because you cannot archive a write-ahead log for a database that is asleep.

The move, concretely

The site does not move. Only the connection string does.

1. Get the raw connection string. This one trips people up: it is not in the dashboard. It comes from the CLI.

netlify database status --show-credentials

or, if you want it as parseable output:

netlify database connect --json

2. Copy the data. Netlify DB is Neon underneath, so it is an ordinary Postgres connection string. Paste it into the Netlify DB migration page: it provisions a database, copies your schema and data in one pass, and reads without writing anything back to the source. Add --branch <name> to the CLI command above if you want to copy a deploy-preview branch rather than production. The long-form version of the same copy, including how to verify your row counts landed and the pooled-connection-string gotcha, is in Migrating from Neon to Layerbase, since the source is the same Postgres either way.

If you would rather do it by hand, it is the boring command:

pg_dump "$NETLIFY_DB_URL" --no-owner --no-acl \
  | psql "$LAYERBASE_DB_URL"

3. Swap the environment variable and redeploy. Set DATABASE_URL in your Netlify site's environment variables, and change your code from the zero-argument call to the explicit one:

// before
const db = getDatabase()

// after
const db = getDatabase({ connectionString: process.env.DATABASE_URL })

That signature exists in the SDK already, which is a nicer exit than most platforms give you. If you are using a plain driver or an ORM, there is nothing to change at all beyond the variable.

Deploy. That is the whole migration.

What does not travel

Be honest with yourself about this part before you start.

The automatic per-preview branch goes away. You can absolutely give previews their own database, and branching makes creating one instant, but the wiring is now yours: create the branch, set the branch-scoped variable, tear it down. Netlify did that for you. If deploy previews are central to how your team works and nobody wants to own that glue, this alone is a good reason to stay.

Anything else keyed to the Netlify environment. If you have functions relying on getDatabase() resolving with no arguments, they need the explicit connection string. That is a small edit, and it is a real one.

Extensions. Check your extension list before you migrate rather than after. Standard Postgres extensions are standard, but "I assumed it was there" is how a migration turns into an evening.

When staying is fine

I would rather you not migrate than migrate for sport. Stay if:

• Your credit usage has never surprised you. If the meter has never been a question, it is not a problem you have.
• Deploy previews with isolated data are the feature your team lives on, and you do not want to own that wiring.
• The database exists to serve exactly one Netlify site and will die with it.
• You are still building and nobody is using it yet. Ship first, move later, it stays easy.

The signals to move are specific: you have started checking the bill rather than paying it, something outside Netlify needs the same data, you need a second kind of database, or you have realized that your data and your CDN should probably not share a vendor relationship.

FAQ

Is Netlify DB just Neon?

Yes. It is Neon Postgres that Netlify operates and resells, with Netlify's provisioning and billing on top. General availability was April 28, 2026, and the beta was frozen on April 13, 2026. That is good news for portability, because what you have underneath is real Postgres with a real connection string.

Where is my Netlify DB connection string?

In the CLI, not the dashboard. Run netlify database status --show-credentials, or netlify database connect --json if you want machine-readable output.

What does Netlify DB storage cost per GB?

Netlify has not published a per-GB rate. Storage was free until July 1, 2026 and has been billed since, out of the same credit balance as compute and bandwidth. As of 2026-08-28 the only way to find out what your storage costs is to look at your invoice, which is a fair thing to hold against the model.

Can I claim my Netlify database into my own Neon account?

That was documented for beta databases. The GA documentation does not describe a claiming step, so do not plan around it. If getting your data out on your own terms matters to you, the reliable answer is the one that has always worked: pg_dump.

Do I have to leave Netlify to move the database?

No, and that is the point. The site stays deployed exactly where it is. You create a Postgres elsewhere, copy the data, set DATABASE_URL, and change getDatabase() to getDatabase({ connectionString }). One redeploy.

Will I lose per-deploy-preview databases?

The automatic wiring, yes. Branching itself, no: instant branches work on 16 Layerbase engines regardless of where the app deploys. The difference is that you create and point the branch instead of the platform doing it silently. That is a real trade and worth weighing honestly.

The wrap-up

Netlify made a sensible call. Reselling Neon rather than building a Postgres is the right kind of engineering laziness, the provisioning is genuinely frictionless, and per-preview branches solve a real problem elegantly.

The part I would push back on is structural rather than technical. When your database is a feature of your deploy platform, priced in the deploy platform's units and billed on the deploy platform's schedule, you have quietly agreed that changing hosts means moving your data. Databases outlive frameworks, hosts, and rewrites. Mine has outlived two of each.

If you want the price to be a number instead of a function, take your connection string to the Netlify DB migration page, or start an empty Postgres and point the site at it. The site never notices.