Northflank alternatives: a preview environment is not a database branch
Short version: Northflank is an application platform with six managed databases attached to it. Its preview environments give every pull request its own copy of the whole stack, which is a real feature, and the database inside that copy starts empty unless you seed it with a job or restore it from a backup you already had running. Layerbase only hosts databases, 18 of them, and a branch is a copy-on-write clone of the live data that lands in seconds, needs no backup to exist first, does not use one of your database slots, and hibernates when nothing is connected. If you want one platform to build and run the whole app, Northflank is the better product and this post will say so. If what you actually want is the database branch, the two are not the same thing, and the difference is the whole post.
What Northflank actually is
Northflank builds and runs services from a git repository or a container image, schedules jobs and cron, runs GPU workloads, and can do all of that inside your own AWS, GCP, Azure, or Kubernetes account. That is the product. The databases are addons that sit next to the services on the same control plane. Verified 2026-09-05 from their addon documentation, the managed addons are PostgreSQL, MySQL, MongoDB, Redis, MinIO, and RabbitMQ.
We do not compete with the platform half at all. We host databases and nothing else. If Northflank is where your app runs, the addons are a convenience, and the only question this post answers is whether the convenience does what you think it does when a pull request opens.
What a preview environment gives you
This part is good and I want to describe it accurately. From Northflank's preview documentation, verified 2026-09-05: a preview blueprint "creates preview environments when pull requests are opened and updates them when new commits are pushed," and each one "is an isolated instance of your application with its own services, databases, and URLs." You choose whether it is deleted when the PR closes, when it merges, or after a set number of days with no new commits.
So every pull request gets its own services, its own database, and its own URL, and it all goes away on its own. That is the right shape, and most platforms do not offer it.
The database in that environment is created fresh. Their docs give you two ways to put data in it. You can "run a one-off job after the database is ready to load fixtures or seed data." Or, in their words, "alternatively, fork your database from a snapshot to restore pre-seeded data more efficiently."
The second option is the one people mean when they say Northflank has branching, so it is worth reading exactly what a fork is.
What a fork is, on Northflank
Verified 2026-09-05 from Fork an addon and Backup, restore, and import data.
A fork is a restore. "You must have an existing addon that contains a disk backup of the same major version as the fork addon." You pick the backup, and a new addon "will begin provisioning" that "will be entirely separate from the source addon." In a template, which is what a preview blueprint is, you can point at the latest backup instead of a specific one, which is what makes it usable per pull request.
Four things follow from that, and none of them is a criticism of the engineering. They are just what a restore is.
It needs a backup to exist first. The fork reads from a disk snapshot, so you need a backup schedule already running on the source. Northflank lets you configure up to three schedules per database, one hourly, one daily, and one weekly. That means the data in your preview is as old as the most recent snapshot. Hourly at best.
It scales with the data. Snapshots are incremental for storage, which is efficient. A fork still restores the whole volume into a new addon and provisions that addon. Their docs do not publish a time, and I am not going to invent one, but it is not instant, and it grows with the database.
It covers three of the six addons. Forking is supported for "PostgreSQL, MongoDB, MySQL." Redis, MinIO, and RabbitMQ start empty in a preview. For a cache that is often fine, and I am noting it because it is the boundary, not because it is a flaw.
It is a whole new addon. The fork runs on its own compute plan, metered per hour, for as long as the pull request is open. I read the preview docs, the addon docs, and the billing docs looking for any pause, sleep, or scale-to-zero behavior for addons and found none. The pricing page describes the free sandbox as "Always-on-compute, no sleeping," with a smiley, and that is the model across the board.
What a branch is, on Layerbase
A branch on Layerbase Cloud is a copy-on-write clone of the running database's data directory, taken on the server, on storage that is built for exactly this. Branching with any database has the mechanics. What matters for the comparison:
- It starts from the data as it is right now, not as of the last snapshot. No backup schedule has to exist.
- It lands in seconds, and the time does not grow with the size of the database, because the blocks are shared and only the writes diverge.
- It gets its own hostname, its own connection string, and its own credentials, and it does not consume one of your plan's database slots.
- It hibernates when nothing is connected and wakes on the next connection, so a stack of preview branches that nobody is looking at is a stack of nothing.
- It works on 16 of the 18 Cloud engines: Postgres, MySQL, MariaDB, Redis, Valkey, FerretDB, libSQL, SQLite, DuckDB, TypeDB, ClickHouse, Meilisearch, Qdrant, QuestDB, InfluxDB, and Weaviate. The two exceptions are CouchDB and TigerBeetle, which store their cluster identity inside the data and are excluded by design.
So Redis branches. So does the vector store and the search index. The Northflank preview gives you an empty Redis and no vector store at all; the Layerbase branch gives you the cache as it was, and Qdrant as it was, on the same command.
One honest note in the other direction. Taking the branch means taking a consistent snapshot of the source, which is a brief pause. Northflank forks read from a backup that already exists, so the source never notices. Neither matters at the scale of a preview, and I mention it because I would rather you hear it from me.
Wired into Vercel, every preview deployment gets its own branch with the connection string injected for you; that integration covers PostgreSQL today, and branching itself covers the 16 engines above. The GitHub App maps a repository to a database and keeps a staging branch that is reset against production whenever a pull request merges into your base branch, with read-only access to the repo.
Side by side
| Northflank preview database | Layerbase branch | |
|---|---|---|
| Starts with | Empty, or restored from an existing backup | The live data, as of now |
| Mechanism | Restore a disk snapshot into a new addon | Copy-on-write clone |
| Prerequisite | A backup schedule already running | None |
| Time to ready | Provisioning plus restore, grows with data | Seconds, independent of size |
| Engines with data | PostgreSQL, MySQL, MongoDB | 16 of 18 |
| Engines that start empty | Redis, MinIO, RabbitMQ | None |
| While the PR sits open | Metered compute, always on | Hibernates, wakes on connect |
| Counts as a database | Yes, it is a new addon | No |
The money
Northflank's prices, verified 2026-09-05 from northflank.com/pricing: $0.01667 per vCPU per hour, $0.00833 per GB of memory per hour, $0.15 per GB per month for SSD, prorated to the second. Predefined compute plans start at $2.70 a month.
So a forked preview database on the smallest plan, open for a month, is about $2.70 plus storage. That is not expensive, and I want to be fair about it. The number to watch is not the per-preview price, it is that every open pull request is its own addon and its own set of services, each on its own meter, and the meters run whether anybody looks at the preview or not. That is the correct model for compute, and Northflank is a compute platform. It is just not how a branch has to work.
On Layerbase there is no meter to run. Free is $0 with no card: 2 databases, 5 GB, 8 Standard engines, and 1 branch per database. Solo is $5 a month: 2 databases, 10 GB, 3 branches per database, and a 768 MB always-on pool for the one that must never sleep. Pro is $15 a month: up to 10 databases, 25 GB across them, every one of the 18 engines, and 10 branches per database. A branch is inside the flat price at every tier. Opening a pull request does not change the bill.
Northflank's free tier, verified 2026-09-05 from their billing documentation, is 2 services, 2 jobs, and 1 addon, and "all users must add a payment method to start creating resources on Northflank, regardless of plan selection." With one addon on the sandbox, a preview environment that needs its own database is already a paid feature.
Where Northflank wins
You want to run the app there. Builds from git, services, jobs, cron, GPUs, your own cloud account. We do none of that. If you are choosing a platform to deploy on, Northflank is a real one and this post has nothing to say against it.
You want the whole stack in one preview. Northflank previews the services and the database in one control plane. Layerbase gives you the database branch and your deploy platform gives you the app preview. With Vercel that is one integration and it feels like one thing. Anywhere else it is two things.
You need MinIO or RabbitMQ. We do not host object storage or a message broker. Our Valkey databases expose a built-in HTTP queue, which covers a lot of what people reach for RabbitMQ to do, but it is not RabbitMQ.
You want forks that never touch the source. Restoring from a backup means production does not pause, even briefly. If that matters more to you than the data being current, their model is the one you want.
Keeping Northflank and adding branches
You do not have to choose. A Layerbase database is a connection string, and Northflank services read environment variables. Run the app on Northflank, point it at a Layerbase database, and in the preview blueprint replace the "create addon" step with a one-off job that runs lbase cloud branch app-db pr-482 with the Layerbase CLI and exports the branch connection string. You keep their preview environments and get a branch with real data instead of an empty addon or a restore. When the PR closes, delete the branch, or let it hibernate and delete it later. The database itself starts at cloud.layerbase.com/create, on the Free plan if you want to try the branch before you move anything.
FAQ
Does Northflank have database branching?
Not in the copy-on-write sense. Northflank can fork an addon, which restores an existing disk backup into a new, separate addon. It is supported for PostgreSQL, MySQL, and MongoDB, it requires a backup to already exist, and the new addon runs on its own metered compute. Verified 2026-09-05 from their documentation.
Do Northflank preview environments include production data?
Not by default. The database in a preview environment is created fresh. Their docs offer two ways to add data: a one-off job that loads fixtures, or a fork from the most recent backup of an existing addon.
Can I branch Redis?
On Northflank, no: Redis, MinIO, and RabbitMQ are not forkable, so they start empty in a preview. On Layerbase, yes: Redis and Valkey are two of the 16 branchable engines, and a branch carries the keys as they were.
Does a Layerbase branch cost extra?
No. Plans are flat and branches are included: 1 per database on Free, 3 on Solo, 10 on Pro. A branch does not use one of your database slots and there is no hourly meter on it.
Does Northflank's free tier require a credit card?
Yes. Their billing documentation says a payment method is required to create resources on any plan, including the free sandbox. Layerbase Free asks for no card.
Can I use Layerbase branches with an app running on Northflank?
Yes. Point the Northflank service at a Layerbase connection string, and create the branch from a job in your preview blueprint with the Layerbase CLI. The section above walks through it.
Keep reading
- Preview environment platforms in 2026: what is in the database when the preview comes upEvery platform on this list will give a pull request its own URL. The question that sorts them is what is in the database behind that URL: nothing, a restore of last night's backup, or the live data as of right now. Here is where each of eleven platforms lands, quoted from their own docs, and what a preview costs while the PR sits open.
- Branching with any databaseNeon branches Postgres. PlanetScale branches MySQL. Layerbase branches all of them, because branching happens at the filesystem, not inside the engine. Here is how it works.
- Redis Cloud alternatives: pay for the modules, or stop paying for themRedis Cloud prices itself around the module story: search, JSON, time series, vector sets, Active-Active. If you use those, the bill is buying something real. If you use Redis as a cache, a session store, or a queue, you are paying the module premium for a key-value store. Here is what each tier buys, where a flat plan fits, and when to stay.
- Layerbase vs Crunchy Bridge: two ways to buy managed PostgresCrunchy Bridge is Postgres specialists selling instance-hours across AWS, Azure and GCP. Layerbase is a flat monthly price, 18 engines and branching. A head-to-head on pricing, versions, extensions, HA, backups and placement, with worked examples.