Preview environment platforms in 2026: what is in the database when the preview comes up
Short version: "preview environment" has come to mean two different products that happen to share a name. One is a preview of the app: build the branch, give it a URL, tear it down on merge. Vercel did that first and nearly everyone does it now. The other is a preview of the data: a database the branch can write to, that looks like production, that nobody else's branch is touching. That second thing is where the platforms split, and the split is not "has it or not." It is what the database contains when the preview comes up. Three answers exist: nothing, a restore of a backup, or a copy-on-write clone of the live data. Every claim below was verified against the vendor's own documentation on 2026-09-06, with the page linked, so you can check the sentence that matters to you.
The question that sorts the field
Ask one thing of each platform: when a pull request opens and the preview database is created, what is in it?
Nothing. The database is provisioned fresh. You seed it with fixtures from a job, or you run migrations against an empty schema. Isolation is real. Fidelity is whatever your seed script produces, which is never what production looks like.
A restore. The database is created by restoring a backup of production. Fidelity is good, as of whenever the backup was taken. The cost is that a backup has to exist first, the restore takes time proportional to the data, and the result is a whole new database on its own compute.
A copy-on-write clone. The storage layer clones the live data directory without copying the bytes, and only writes diverge. The branch is ready in seconds regardless of size, reflects the data as of right now, and costs nothing until it is written to. This is what Neon does for Postgres and what we do for 16 engines.
Hold that framing and the table stops being a feature grid and becomes a sort.
The matrix
| Platform | What a PR gets | Database in it | Data in it | Engines that carry data | Idle cost while the PR is open |
|---|---|---|---|---|---|
| Vercel | App preview with its own URL | None from Vercel itself; per-environment env vars point at a database you bring | Whatever your database provider does | n/a | App: nothing. Database: your provider's rule |
| Neon | A database branch | Yes | Copy-on-write clone of the parent, instant | Postgres | Compute scales to zero after 5 minutes |
| Xata | A database branch | Yes | Copy-on-write clone; branches scale to zero | Postgres | $0.012/hr plus $0.28/GB-month; no free plan, 14-day trial |
| Supabase | A preview branch, its own Supabase instance | Yes | "Data-less by default"; opt in via seed file or Include data | Postgres | $0.01344 per branch per hour, not covered by the Spend Cap |
| PlanetScale | A development branch | Yes | Schema only; Data Branching restores "from most recent backup" | MySQL (Vitess); Postgres from a backup | Billed while the branch exists, prorated to the millisecond |
| Turso | A branch database | Yes | From the existing database or a point-in-time snapshot | SQLite / libSQL | Counts toward your plan's database quota |
| Northflank | Whole stack: services plus addons | Yes | Empty, or a fork restored from an existing disk backup | PostgreSQL, MySQL, MongoDB forkable; Redis, MinIO, RabbitMQ start empty | Metered compute, always on |
| Render | Whole Blueprint | Yes | "These instances do not copy any data from existing services" | None carry data | Metered; previews need Pro or higher |
| Railway | PR environment | Yes | Empty; a Copy Volume Data feature was announced 2024-12-18, see below | See below | Metered usage |
| Qovery | Clone of the production environment in your cluster | Yes | "Only the instance configuration will be copied, not the data" | None carry data | Your cloud bill |
| Bunnyshell | Ephemeral Kubernetes environment in your cluster | Yes, as containers | Via "native connectors for Neon, PlanetScale, Xata", i.e. the database provider's branching | Whatever the connected provider branches | Your cloud bill plus the plan |
| Layerbase | A database branch, wired to Vercel or GitHub | Yes | Copy-on-write clone of the live data, seconds | 16 of 18 Cloud engines | Hibernates when nothing is connected; inside the flat plan |
Eleven rows, three real answers. The rest of this post is the sentence behind each cell.
Vercel: the app half, done right
Vercel's environments documentation is clear about what a preview is: "By default, Vercel creates a preview deployment when you push a commit to a branch that is not your production branch" or "create a pull request." Each gets a branch URL and a commit URL. Custom environments like staging exist on Pro and Enterprise, and "every environment can define its own unique environment variables, like database connection information."
That last clause is the whole story. Vercel gives every preview its own compute and lets each environment carry its own DATABASE_URL. It does not give the preview a database. Where the URL points is up to whoever you buy the database from, which is why every database vendor on this list ships a Vercel integration and why the shared dev database is the thing that makes previews flaky.
Neon: copy-on-write, Postgres only
Neon's branching page states the model in one sentence: "A branch is a copy-on-write clone of your data." Branching "creates copy-on-write clones of your database instantly," writes are stored as deltas, and the Neon-managed Vercel integration will "create a branch for each preview deployment." GitHub Actions cover the rest.
The plans page, verified 2026-09-06: Free is $0 with 10 branches per project, 0.5 GB of storage per project, and compute that scales to zero "after 5 min" with no ability to disable it. Launch keeps 10 branches per project and lets you disable scale-to-zero; Scale goes to 25 branches with the idle timer configurable down to one minute or always on.
This is the reference implementation of the third answer, and if your world is one Postgres it is excellent. The ceiling is the engine. Neon rebuilt Postgres storage to get here, and that work does not transfer to the Redis next to it.
Xata: the same answer as Neon, without the free tier
Xata is not the product it launched as. The Airtable-style data platform and its 15 GB free tier are gone; what is left, verified 2026-09-06 on xata.io/pricing, is a Postgres platform whose headline is "copy-on-write branching" for isolated Postgres branches "without multiplying storage and compute costs," with "scale-to-zero" for idle branches. That puts it in the third answer alongside Neon, and it is the only other vendor on this list there.
The plans are Open Source (self-host on their Apache-2.0 core), Xata Cloud "starting at $0.012/hr + $0.28/GB/mo storage," and BYOC on a quote. The trial is 14 days with no card, and there is no free plan after it. So the comparison with Neon is narrow and clean: the same branching model, Postgres only in both cases, and the difference is that Neon's Free plan is permanent and Xata's is a fortnight. If you are choosing between them for previews, that is the deciding line.
Supabase: a real preview branch that starts empty
Supabase branching, verified 2026-09-06: a preview branch is "automatically deleted when a PR is merged or closed," and each one has "its own Supabase instance and API credentials." Migrations are applied on creation. Data is a choice: branches are "data-less by default" and do "not start with any data or storage objects from your main project." You can "start your branches with data" with "a seed file if using the GitHub integration, or the Include data option if you create the branch from the dashboard."
So the honest classification is: empty by default, with a data option in the dashboard flow. The pricing page puts branching on Pro ($25 a month) and Team ($599) at "$0.01344 per branch, per hour"; the Free plan does not include it. The usage documentation adds the line to read twice: "Branches are not covered by the Spend Cap," and Compute Credits do not apply to them. Delete branches you are done with; nothing pauses them for you.
PlanetScale: schema branches, with data as a restore
PlanetScale's branching is the best schema workflow in the industry and it is worth being precise about what it branches. The Vitess branching docs, verified 2026-09-06: "A new development branch will not have any data stored in it unless you restore from a backup." Deploy requests review and merge schema changes with non-blocking migrations, which is the reason to be on PlanetScale.
For data there is Data Branching, a toggle in database settings that lets a new branch seed "from most recent backup," so "your new branch has the latest dataset to work with." It is a restore, as of the last backup, and the docs carry a warning worth quoting: seeding from a production branch creates a production branch billed at production rates.
PlanetScale Postgres is a different product under the same name. Branches are "isolated database deployments"; you create one empty, or "from backup" with schema and data. There are no deploy requests on Postgres yet, so you "manually copy your changes from development to production branches." Development branches run on PS-DEV instances from $5 a month, and "new branches incur additional charges." No free tier on either engine.
Turso: a branch is another database
Turso's branching docs: a branch is "a separate database instance that is created from an existing database," or from a point-in-time snapshot. "Database branches are completely separate from the original database," "branches count towards your plan's database quota," you need a new token to connect, and you "manually delete the database branch when you no longer need it." Per-PR branching is a CI script. It is a good fit if you are already on the SQLite-at-the-edge model, and not a reason to move there.
Northflank: whole-stack previews, restore-based forks
Northflank is the strongest whole-stack option on this list, and we wrote up the mechanics in full. The short form, all from their preview docs and fork docs: a preview blueprint creates environments "when pull requests are opened," each "an isolated instance of your application with its own services, databases, and URLs." The database starts fresh; you "run a one-off job after the database is ready to load fixtures," or "fork your database from a snapshot." A fork requires "an existing addon that contains a disk backup of the same major version," is supported for "PostgreSQL, MongoDB, MySQL," and produces an addon "entirely separate from the source." Redis, MinIO, and RabbitMQ start empty. Nothing in their docs pauses an addon, and a payment method is required on every plan.
Second answer, done well, for three of six addons, on always-on metered compute.
Render: previews of the Blueprint, data not included
Render's preview environments, verified 2026-09-06: "Render creates a preview environment for every PR against your Blueprint's linked branch," keeps it current on every commit, and "automatically destroys them when the original pull request is merged or closed." On data, the sentence is unambiguous: "A preview environment creates new instances of the services and datastores defined in your Blueprint. These instances do not copy any data from existing services." Seeding is an initialDeployHook. "Preview environments require a Pro plan or higher."
First answer, cleanly documented, paid.
Railway: PR environments, and a feature I could not find
Railway's environments guide, verified 2026-09-06: PR environments "are created when a Pull Request is opened on a branch and are deleted as soon as the PR is merged or closed." The guide describes service configuration, variables, and staged changes; it says nothing about what happens to volume data.
The history matters here. On 2024-12-18 a Railway employee replied on their feedback board: "we recently released a feature 'Copy Volume Data' that we hope addresses your issue. The volume data from your base environment will be copied to a new PR environment," with a link to a docs anchor. That anchor is not on the current environments page, and later replies on the same thread, from 2025 on, are users saying they cannot find the feature. I am not going to call it removed, because Railway has not said so. I am going to say: as of 2026-09-06 it is not documented, and you should look for it in your own project settings before you build a workflow on it. If it is there and works, Railway is a restore-style option. If it is not, a Railway PR environment's database is empty. Plans, from their pricing page: Free at $0 with $1 of credit, Hobby $5, Pro $20.
Qovery and Bunnyshell: the environment is the unit
These two are a different category, and I am including them because "preview environment platform" searches land on them. Both run in a Kubernetes cluster you bring, and both clone the whole environment per pull request.
Qovery's environment docs: when a PR opens, Qovery "automatically creates a clone of your production setup," deleted "when PR is merged" or "when PR is closed without merging." On the database inside it, their database docs are explicit: "only the instance configuration will be copied, not the data contained within the database." Their answer to data is RepliByte, an open source seeding tool that copies and anonymizes a dump. First answer, with a tool for turning it into the second.
Bunnyshell: "Ephemeral Environments are designed to be identical replicas of production environments (except in size)," running on "YOUR Kubernetes cluster. Your code and data never leave your infrastructure." The data line is "Database cloning: native connectors for Neon, PlanetScale, Xata. Seed data automatically." Read that carefully. Bunnyshell does not branch a database; it calls Neon or PlanetScale to do it and wires the result in. So the data answer is whichever of those providers you connected, and the engine list is theirs. The free tier is five environments, no card.
Layerbase: the third answer, on 16 engines
A branch on Layerbase Cloud is a copy-on-write clone of the running database's data directory, taken on the server on storage built for it. Branching with any database has the mechanics. What it means for a preview:
- The branch reflects the data as of now. No backup schedule has to exist first.
- It lands in seconds and the time does not grow with the database, because blocks are shared and only writes diverge. The source pauses for the moment it takes to reach a consistent snapshot, which is the one place a restore-based fork has the edge.
- It gets its own hostname, connection string, and credentials, and 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 nobody is looking at costs nothing.
- It covers 16 of the 18 Cloud engines: Postgres, MySQL, MariaDB, Redis, Valkey, FerretDB, libSQL, SQLite, DuckDB, TypeDB, ClickHouse, Meilisearch, Qdrant, QuestDB, InfluxDB, and Weaviate. CouchDB and TigerBeetle are excluded by design because they store cluster identity inside the data.
The wiring: the Vercel integration writes the database environment variables into your project per environment, points preview deployments at a staging branch by default or at a separate branch forked from production, and can reset that branch on deploy or on merge so previews start from a fresh copy. It covers PostgreSQL today. The GitHub App maps a repository to a database and keeps a staging branch that is reset against production whenever a pull request merges, with read-only access to the repo.
Branches are inside the flat price at every tier: Free is $0 with no card, 2 databases, 5 GB, 8 Standard engines, and 1 branch per database. Solo is $5 a month with 3 branches per database and a 768 MB always-on pool for the one that must never sleep. Pro is $15 a month with up to 10 databases, 25 GB across them, every engine, and 10 branches per database. Opening a pull request does not change the bill.
How to choose
Your whole world is one Postgres, and you want the branch to be a first-party feature of the deploy platform. Neon, through the Vercel Marketplace. It is the cleanest single-engine answer and the free tier is real. Xata has the same branching model and no free plan, so it only wins if something else about it does.
You want Auth, Storage, and Realtime in the same box as the database. Supabase. Turn on Include data or ship a seed file, budget the hourly rate, and delete branches by hand.
Schema change review is the thing you actually need. PlanetScale Vitess. Deploy requests have no equal. Accept that data is a restore and that there is no free tier.
You want the app and the database previewed together by one platform. Northflank if you want managed addons with restore-based forks; Render if empty previews plus a seed hook is enough and you are on Pro; Qovery or Bunnyshell if you are already on Kubernetes in your own cloud.
You have more than one engine and you want the preview to carry real data on all of them. That is the case nobody above covers, and it is the case we built for. Postgres plus a cache plus a vector store is three branches from one command, each with the data as it was, each asleep until something connects. Start at cloud.layerbase.com/create on the Free plan and branch the first one before you move anything.
FAQ
Which preview environment platforms clone production data into the preview database?
By copy-on-write of the live data: Neon (Postgres), Xata (Postgres), and Layerbase (16 engines). By restoring a backup: Northflank (PostgreSQL, MySQL, MongoDB forks), PlanetScale Data Branching (from the most recent backup), and PlanetScale Postgres branches created from a backup. Supabase is empty by default with an Include data option. Render, Qovery, and Railway's documented behavior create an empty database. Verified against each vendor's documentation 2026-09-06.
Does Vercel give preview deployments a database?
No. Vercel provides the app preview and lets each environment carry its own environment variables, including a database connection string. The database comes from a provider integration: Neon, Supabase, Layerbase, and others write the variable for you.
Is a Northflank fork the same as a Neon branch?
No. A Northflank fork restores an existing disk backup into a new, separate addon on its own metered compute, for PostgreSQL, MySQL, and MongoDB. A Neon branch is a copy-on-write clone of the live data with compute that scales to zero. Both isolate the preview; they differ in freshness, time to ready, engine coverage, and idle cost.
Do Railway PR environments include database data?
Railway's environments guide does not document copying volume data into a PR environment as of 2026-09-06. A Railway employee announced a Copy Volume Data feature on 2024-12-18, and later replies on that thread report not finding it. Check your project settings before relying on it.
How much does a preview database cost while a pull request is open?
Supabase: $0.01344 per branch per hour on Pro and Team, outside the Spend Cap. PlanetScale: the branch's compute for as long as it exists, prorated to the millisecond. Northflank and Render: metered compute, always on. Neon: compute scales to zero after five minutes, so an idle branch costs storage only. Layerbase: nothing beyond the flat plan; branches hibernate when idle and do not use a database slot.
Can I branch Redis or a vector database for a preview?
On Layerbase, yes: Redis, Valkey, Qdrant, Weaviate, and Meilisearch are among the 16 branchable engines, and a branch carries the keys, points, or index as they were. On the other platforms in this post, the cache and vector store in a preview start empty or are not offered.
Keep reading
- Northflank alternatives: a preview environment is not a database branchNorthflank gives every pull request its own stack, and the database in that stack starts empty unless you seed it or restore it from a backup you already had. Here is exactly how their forks work, what a copy-on-write branch does differently, what each one costs while a PR sits open, and the cases where Northflank is the right answer.
- Neon alternatives: when the CU-hour meter stops matching the workNeon is excellent serverless Postgres with a bill shaped like compute-hours and branch-months. That shape fits a bursty production app and fights a stack of small, mostly idle databases. Here is what Neon actually is, where the meter bites, the current plan numbers, and an honest list of reasons 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.
- Prisma Postgres alternatives: the plan with neither meterPrisma Postgres bills per operation, Neon bills per CU-hour, and Prisma frames the whole decision as a choice between those two meters. There is a third option: a flat plan with no meter at all. Here are the current Prisma numbers, the arithmetic for a chatty app, where operations pricing genuinely wins, and how to move with the direct TCP string.