Netlify Database is a managed Postgres wired directly into the deploy lifecycle, and its most interesting feature is not that it is managed — plenty of things are — but that every deploy preview gets its own database branch, copied from production at the moment the preview was created.
That solves a real and persistent problem: the staging database that has silently drifted from production until it stops telling you anything useful. It also introduces a set of questions about billing, portability and what happens when the platform’s assumptions do not match yours. Both halves are worth understanding before you build on it.
Table of contents
- The problem branching actually solves
- Automatic migrations, and where the sharp edge is
- The billing model is the thing to read carefully
- Portability, which is the question to settle first
- When platform-native is the right call
- How this fits the rest of the stack
- FAQ
The problem branching actually solves
The conventional arrangement is one shared staging database. Everyone points at it, everyone’s migrations land in it, and over months it drifts: leftover test rows, half-applied schema changes, data shapes that production has not seen in a year.
The consequence is that passing against staging stops being evidence. A migration that works there may fail against production data volumes or against rows that only exist in production. Teams learn to distrust the staging result, which means they are effectively testing in production while telling themselves they are not.
Per-preview database branching changes the shape of that. Each pull request gets a database branch seeded from production, migrations run against it, and the branch is discarded when the preview is. Two people working on conflicting schema changes do not collide, because they are not sharing anything.
It also makes schema review meaningful. A reviewer can open the preview and see the migration applied to realistic data rather than reasoning about a diff. That is a genuine improvement over the standard workflow and it is the main reason to be interested in this category of product.
Automatic migrations, and where the sharp edge is
The platform tracks schema changes in the repository and applies them at the appropriate point in the deploy — on previews and on production deploys — so the schema never drifts from the code that expects it.
When it works, this is exactly right: schema and code version together, and there is no separate deploy-the-migration step for someone to forget.
The sharp edge is that automatic application means a migration runs when a deploy runs, and some migrations must not simply run:
- A migration that rewrites a large table can lock it. On a table with meaningful volume, an automatic apply during a routine deploy is an outage.
- Destructive changes — dropping a column, narrowing a type — are irreversible in a way a code deploy is not. Rolling back the deploy does not restore the column.
- Long-running data backfills belong in a job, not in a deploy step with a timeout.
The discipline that handles this is the expand-and-contract pattern, and it applies regardless of platform: add the new column, deploy code that writes both and reads the old, backfill separately, deploy code that reads the new, and only then drop the old — in a later, separate change. Each step is individually safe and individually reversible.
Automatic migrations reward that discipline and punish its absence more visibly than a manual process does, because the apply happens whether you were ready or not.
The billing model is the thing to read carefully
Platform-native databases frequently sit on credit-based or consumption pricing rather than a fixed monthly plan, and consumption pricing behaves differently from what most people budget for.
Questions worth answering from the documentation rather than from assumption:
- What consumes credit? Compute time, storage, data transfer, or some combination. Each has a different relationship to your traffic.
- Does an idle database cost anything? Some scale compute to zero when unused and some do not. For a low-traffic application the difference is most of the bill.
- Do preview branches consume separately? If each open pull request carries a live database, a team with many open branches is paying for many databases.
- Are there promotional periods? Storage or another dimension being free until a stated date is common, and the date arrives.
Consumption pricing is genuinely good for spiky or low-volume workloads and genuinely unpredictable for a service under sustained load. A fixed-plan database costs the same on your worst day, which is worth something when the worst day is also the day you are busy dealing with the worst day.
Neither model is better in general. What matters is knowing which one you are on and having modelled it at your expected usage rather than at zero.
Portability, which is the question to settle first
The reassuring part: it is Postgres. Your schema is Postgres schema, your queries are Postgres queries, and your ORM does not know or care where the server is. A pg_dump is a pg_dump. That is a much better position than a proprietary data model, and it means the data itself is never trapped.
The parts that do not move are the surrounding conventions: how the connection string is provisioned and injected, the branching behaviour, the automatic migration hook, and any platform-specific client library the template wired in. Those are platform features, and elsewhere you would build or replace them.
Two things keep the exit cheap and cost almost nothing to do from the start:
- Read the connection string from a standard environment variable and connect with a standard Postgres driver. If the application only knows
DATABASE_URL, it runs against any Postgres anywhere. - Keep migrations in a normal framework-agnostic migration tool in the repository, so they can be applied by a command rather than only by a platform hook.
Do those two and the platform becomes a convenience layer over a standard database rather than a dependency. That is the position worth being in, and it is much easier to arrange on day one than to retrofit.
When platform-native is the right call
It fits well when the application already lives on that platform, the team is small enough that operational simplicity outweighs control, traffic is uneven enough that consumption pricing helps, and per-preview branching would genuinely change how the team reviews schema changes.
It fits less well when you need a database reachable from services outside the platform, when you want predictable fixed monthly cost, when you need control over version, extensions, tuning or replication, or when the database is meant to outlive any particular hosting decision.
That last one is the most common reason to keep the database independent. Applications get rewritten and re-platformed considerably more often than databases do. A database that is not tied to where the current version of the application happens to run survives the next architectural change without a migration project.
Either way, use real Postgres, standard connection handling, and migrations in a tool you control. Those three make the hosting decision reversible, which is the only property that reliably matters over a long enough period.
How this fits the rest of the stack
The database is usually the line item that behaves least like the others — always on, growing, and awkward to move once it holds real data — so it is worth pricing deliberately rather than discovering. The RunxBuild hosting calculator shows it beside the service, the storage and the bandwidth on a fixed plan ladder, which is the predictable counterpart to consumption pricing. RunxBuild offers managed MySQL and Postgres with backups, configurable connection limits, user management and private networking — a standard Postgres your application reaches through an ordinary connection string.
Useful related references:
- Branch Deploy on Netlify: How It Works and When to Use One
- Netlify Redirects: The Rules, the Order, and the Portable Parts
- Netlify Forms: What You Get Free, and Where the Ceiling Is
- Databases on RunxBuild
FAQ
What is database branching?
Each deploy preview gets its own copy of the database, seeded from production when the preview is created. Migrations and data changes in that branch do not affect production or other previews, and the branch is discarded with the preview. It removes the shared staging database that drifts until it stops being informative.
Are automatic migrations safe?
For additive changes, generally yes. For anything that rewrites a large table, drops a column, or backfills data, automatic application during a deploy is risky — a table rewrite can lock, and rolling back the deploy does not restore a dropped column. Use expand-and-contract: add, dual-write, backfill separately, switch reads, drop later.
How is a platform-native database billed?
Often on credits or consumption rather than a fixed plan, which suits spiky and low-volume workloads and is less predictable under sustained load. Check specifically whether idle databases cost anything, whether preview branches bill separately, and whether any dimension is free only during a promotional period.
Can I move off a platform-native Postgres later?
The data moves easily — it is standard Postgres and pg_dump works. What does not move is the platform wiring: connection provisioning, branching, and the automatic migration hook. Keep the application reading a standard DATABASE_URL with a normal driver and migrations in a framework-agnostic tool, and the exit stays cheap.
Should my database live on the same platform as my app?
It is convenient when the team is small and the app is not going anywhere. Keep it separate when you need access from outside the platform, want predictable fixed pricing, need control over version and extensions, or expect the database to outlive the current hosting choice — which it usually does, since applications get re-platformed more often than databases do.