# Best database for Next.js and Vercel in 2026

> Postgres is my default for a Next.js app on Vercel. Here is how Layerbase, Neon, Supabase, PlanetScale, Turso, and Convex compare on pricing, connections, and preview database branches.

Published: 2026-05-19
Canonical: https://layerbase.com/blog/best-database-for-nextjs-vercel

For a typical Next.js app on Vercel, I would start with Postgres. Users, accounts, subscriptions, orders: those are relationships, and SQL is a good fit. The hosting decision comes down to the bill, the connection setup, and what happens when you open a pull request.

I build [Layerbase Cloud](https://cloud.layerbase.com/create?engine=postgresql), so that is where I would start if you want a flat database bill and Vercel preview branching. Our integration connects your Vercel project, writes the pooled connection string, and lets you choose a database branch for every git branch. You can keep Postgres, Redis, and search under one account as the app grows.

Neon is a good fit if you want database billing inside Vercel. Supabase makes sense if you also want auth, file storage, and realtime in the same backend. The other options have reasons to exist too. Here is where I would use each one, and the setup details I would check before picking.

## Vercel vs. Postgres: they do different jobs

Vercel hosts your Next.js app. Postgres stores its data. You can use both, and the database does not have to come from the Vercel Marketplace.

The old product called **Vercel Postgres** is no longer available. Vercel says existing databases moved to Neon in **December 2024**. New projects can connect a provider through the Marketplace or configure an external database themselves. That is different from Vercel no longer supporting Postgres. [Vercel's Postgres docs](https://vercel.com/docs/postgres) explain the change.

If you came here looking for a Vercel Postgres replacement, you are choosing a Postgres host. You do not need to change database engines because the old product name went away.

## The shortlist and what it costs

Prices below are in USD, verified against official sources on **October 13, 2026**. These are public direct-provider prices; check the checkout if you buy through a marketplace. Starting prices are not equivalent amounts of compute, and a paid plan's base price may leave usage charges on top.

| Provider | What I would use it for | Free option | Paid pricing to know |
| --- | --- | --- | --- |
| [Layerbase Cloud](https://cloud.layerbase.com/create?engine=postgresql) | Managed Postgres, a flat bill, Vercel preview branches, and other engines in the same account | Development and testing, with sleeping databases | Solo is $5/month; Pro is $15/month. Fixed plan prices, with capacity limits. [Source](https://layerbase.com/pricing) |
| [Neon](https://layerbase.link/neon) | Postgres with usage-based compute and billing inside Vercel through its native integration | 1 GB storage and 100 CU-hours per project per month | Launch compute is $0.106/CU-hour; database storage is $0.35/GB-month, with other billable items. No monthly minimum on direct paid plans. [Source](https://neon.com/pricing) |
| Supabase | Postgres plus auth, storage, realtime, and client APIs | Two active free projects, with 500 MB database size each; pauses after a week inactive | Pro starts at $25/month; it includes $10 in compute credits. Additional compute, branches, and usage can increase the bill. [Source](https://supabase.com/pricing) |
| PlanetScale | Postgres, or its MySQL-compatible Vitess product when that is what you need | [No free plan](https://planetscale.com/docs/planetscale-plans#free-plan) | Single-node Postgres starts at $5/month. High availability is a separate configuration. [Source](https://planetscale.com/pricing) |
| Turso | A SQLite-compatible cloud database and sync workflows | Free plan with usage allowances | Developer is $5.99/month on monthly billing. The $4.99/month figure is the annual-billing equivalent. Usage overages can be enabled. [Source](https://turso.tech/pricing?frequency=monthly) |
| Convex | A reactive backend where you want query subscriptions and backend functions together | Free plan; Starter adds pay-as-you-go usage | Professional is $25 per developer/month, plus usage beyond included resources. [Source](https://www.convex.dev/pricing) |

For Layerbase, Free is for development, testing, and early-stage projects. Once an app is in production and earns recurring revenue, use Solo or Pro. Solo's always-on pool keeps one database awake; Pro gives you a larger pool to allocate. Paying for Pro does not mean all ten databases get unlimited always-on capacity. The [plan details](https://layerbase.com/pricing) spell out what is included.

## Layerbase's Vercel integration and database branching

A Vercel preview URL gives you a separate version of the app. It does not, by itself, give you separate data. If every deployment gets the same production `DATABASE_URL`, the preview is still writing to production.

Our [Vercel integration](/docs/integrations/vercel) handles the database side. Say your app is called `storefront`, with `main` for production and `dev` for staging:

| Git branch | Database used by the deployment |
| --- | --- |
| `main` | Your main `storefront` database |
| `dev` | A staging database branch forked from `storefront` |
| `feature/cart-redesign` | The staging database by default, or the preview source you select |

That last row is the setting to pay attention to. The default is **Shared staging branch**, so feature previews share staging data. You can instead select **Fork of production** or **Fork of staging** to give feature previews one separate shared preview database. Those choices separate preview work from staging, but the feature previews still share that preview database with each other.

For isolation between feature branches, choose **Branch per git branch**. Each feature git branch gets its own writable database branch forked from production, with its connection string scoped to that branch's Vercel deployments. A test order in the cart redesign preview stays in that database branch. It does not appear in production or another feature's preview.

Database branches contain data from their parent at the time of the fork. Later writes stay separate. Merging app code does not merge the preview's rows into production; keep your production schema migrations in your deployment workflow.

### How to connect a Next.js project

1. [Create a Postgres database](https://cloud.layerbase.com/create?engine=postgresql), or use an existing Layerbase database. Check **Instant branches** in its Settings. If branching still needs preparation, finish that before setting up the mapping.
2. Open [Integrations](https://cloud.layerbase.com/integrations), click **Connect Vercel**, and authorize the connection.
3. Create a **New mapping**. Select the database and Vercel project, set your staging git branch, and use the environment variable your app reads, usually `DATABASE_URL`.
4. Choose the database source for other git branches. Select **Branch per git branch** if each feature needs separate data. Enable the environment variable writes you want the integration to handle.
5. Deploy a feature branch. Check that its database branch exists in Layerbase and that the Vercel preview uses the branch-scoped connection string. Test a write in the preview and confirm it stays out of production.

Existing variables are checked before Layerbase takes them over. If a feature branch already has a manually configured variable with that name, per-branch automation skips creating its database branch. Resolve that collision in the mapping instead of assuming the preview has become isolated.

The connection written to `DATABASE_URL` is pooled. If a task needs a direct session, you can opt into the companion `DATABASE_URL_UNPOOLED` variable. Most app queries should use the pooled URL; session-scoped work such as a `LISTEN` connection may need the direct one.

Branching is included within your plan limits: **Free allows one branch per database, Solo three, and Pro ten**. A staging branch uses one of those slots. Per-branch previews can fill the remaining slots, so choose the plan for the number of previews you actually keep open. Storage and capacity limits still apply. See the [branching plan details](/features#branching).

Vercel-only cleanup happens after a branch stops deploying, not immediately when a pull request merges. Use the [GitHub integration](/docs/integrations/github) if you want cleanup tied to repository events. You can also enable staging resets from production, but a reset replaces staging's data, so turn it on only when that is the workflow you want. The [Vercel setup guide](/docs/integrations/vercel) covers those controls.

## When I would pick another provider

### Neon: keep database billing inside Vercel

Neon's [Vercel-managed integration](https://neon.com/docs/guides/vercel-managed-integration) puts database billing on the Vercel invoice, injects connection variables, and offers preview branching when you enable it. If one invoice matters to you, that is a useful reason to choose it.

Its direct paid plans meter compute, storage, and other resources. Scale-to-zero helps with idle databases, but active previews still belong in the cost calculation. Compare your expected usage with a fixed plan rather than treating the lowest advertised number as your future bill. [Neon's pricing details](https://neon.com/pricing) explain the meters.

### Supabase: you want the whole backend

Supabase combines Postgres with auth, storage, and realtime. If you need those services, the bundle can save work. If you already have auth and file storage elsewhere, compare the database portion of the offer with what you actually need.

It also has a [Vercel branching integration](https://supabase.com/docs/guides/deployment/branching/integrations). Branches are [data-less by default](https://supabase.com/docs/guides/deployment/branching), which is a different starting point from copying an existing Layerbase database's data. Seed the test data your preview needs.

Budget for previews separately: default Micro branch compute starts at **$0.01344/hour**, and compute credits do not cover branching compute. Other branch usage can add charges too. [Supabase's branch billing docs](https://supabase.com/docs/guides/platform/manage-your-usage/branching) explain the calculation.

### PlanetScale: choose the database configuration you need

PlanetScale's $5 starting price is single-node Postgres. Its high-availability option uses a primary and two replicas across three availability zones. That distinction matters more than the entry price if your requirements include replica failover. [PlanetScale's pricing page](https://planetscale.com/pricing) separates those configurations.

For MySQL-compatible workloads, look at its Vitess offering. Do not assume a feature described for Vitess also works the same way on PlanetScale Postgres; check the product-specific docs before choosing it for a migration or branching workflow.

### Turso: your app fits SQLite

Turso is worth considering when you want a SQLite-compatible database or local data with cloud sync. Its [docs distinguish Turso Cloud, Turso Database, and sync](https://docs.turso.tech/introduction), so pick the deployment model you need before comparing it with a hosted Postgres service.

I would keep Postgres for an app already built around its SQL features and extensions. Moving from Postgres to a SQLite-compatible engine is a database change, with schema and query work to check, rather than just a new host.

### Convex: reactive queries are central to the app

Convex stores documents and reads and writes them through backend functions rather than SQL. Its [reactive queries](https://docs.convex.dev/realtime) can fit a collaborative app or a live dashboard where updates need to reach connected clients.

For a relational app with a few live screens, I would first check whether the existing Postgres backend can handle them. Convex changes your query code and backend architecture. Read the [database model](https://docs.convex.dev/database/overview) and price the developer seats as well as usage.

### Firebase: you already want its client workflow

Firestore offers document storage, realtime listeners, and offline support. If those are the features your web or mobile app needs, [Firebase's Firestore docs](https://firebase.google.com/docs/firestore) are the place to start. I would not switch an existing relational app to it just because the frontend runs on Vercel.

## Connection setup matters as much as the provider

There are three things I would check before calling the database setup finished:

- **Pooling:** serverless concurrency can exhaust a database's direct connections. Use the provider's pooled endpoint and manage the application's connection pool too. Vercel's [connection pooling guide](https://vercel.com/kb/guide/connection-pooling-with-functions) covers the application side.
- **Region:** keep the app's database-calling functions close to the database. A global CDN does not put your SQL queries next to the data. [Vercel's function region docs](https://vercel.com/docs/functions/configuring-functions/region) explain where the code runs.
- **Preview scope:** verify which database receives a write from each deployment. A variable labeled Preview can still contain a production connection string.

Keep database credentials on the server. Next.js [exposes `NEXT_PUBLIC_` variables to the browser](https://nextjs.org/docs/app/guides/environment-variables), so do not put a Postgres password in one.

## Redis, files, search, and vectors

You may need more than Postgres, but I would add each piece when there is a reason for it.

| Need | A reasonable starting point |
| --- | --- |
| Sessions, rate limits, or a shared cache | Redis or Valkey; [Layerbase Redis](https://cloud.layerbase.com/create?engine=redis) keeps it alongside your database |
| Uploaded files | Object storage such as Vercel Blob, R2, or S3; compare storage and transfer charges for your workload |
| Full-text search | [Postgres full-text search](https://www.postgresql.org/docs/current/textsearch.html), then [Meilisearch](https://cloud.layerbase.com/create?engine=meilisearch) if you need a separate search service |
| Vector search | Evaluate [pgvector](https://github.com/pgvector/pgvector) in Postgres, or a dedicated service such as [Qdrant](https://cloud.layerbase.com/create?engine=qdrant) when the workload calls for it |

Vercel KV is also retired. Vercel says existing stores moved to Upstash Redis in December 2024. Use an external Redis provider or a current Marketplace integration; do not build a new setup around the old Vercel KV product. [Vercel's Redis docs](https://vercel.com/docs/redis) cover the replacement.

There is no universal row count where you must move search or vectors out of Postgres. Measure the queries, indexes, memory use, and latency you need before adding another service. The [vector database comparison](/blog/vector-databases-compared-2026) goes through the options.

For a new app, I would [create a Postgres database on Layerbase](https://cloud.layerbase.com/create?engine=postgresql), connect Vercel, and test the preview workflow before the first production release. You will know where the data goes, what the database costs, and what happens when someone opens the next pull request.

## FAQ

### What is the best database for Next.js on Vercel?

My default is Postgres. I would use Layerbase Cloud for a flat database bill and integrated Vercel preview branches, Neon for billing through Vercel, or Supabase when the app needs its bundled backend services. The framework does not require one particular host.

### Does Layerbase create a database for every Vercel preview?

It can create one database branch per git branch when you select **Branch per git branch**. Repeated deployments of that git branch use its database branch. The default mapping shares staging data across feature previews, so choose the mode deliberately. Your plan's branch limits still apply.

### Does Vercel still offer Vercel Postgres?

No. Existing Vercel Postgres databases moved to Neon in December 2024. Vercel still supports connecting Postgres providers to your projects, including through its Marketplace.

### Can I use a database outside the Vercel Marketplace?

Yes. Layerbase connects from its own dashboard and writes the connection variables to your Vercel project. You can also configure an external provider's connection string yourself. The database and the app host do not need to bill together.

### Will a database branch merge its data back into production?

A Layerbase branch is a separate writable database. Merging a git branch does not copy its test data into production. Apply the schema migrations you intend to ship through your production deployment process.

### Should I change databases if the app is already working?

Only if there is something to fix: the bill, preview isolation, missing services, or an operational requirement. For an existing Postgres app, start by comparing hosts that keep Postgres. If you want to move to Layerbase, the [migration guides](/migrate) cover the supported paths and what still needs checking.