Best Databases for Vercel: Neon vs Supabase vs Upstash

If you deploy on Vercel, you will need to pick a database sooner or later, and the names that come up first are Neon, Supabase, and Upstash. The first thing to know is that they are not three versions of the same product. Neon and Supabase are Postgres databases. Upstash is mainly a Redis service, built for caching, rate limiting, queues, and other fast key-value work. So the real question is often not 'which one,' but 'which Postgres, and do I also need Redis.'

Here is the short answer. For most Vercel apps, start with Neon or Supabase as your main database. Choose Neon if you want plain, serverless Postgres that scales to zero and gives you database branches for preview deployments. Choose Supabase if you also want auth, file storage, and realtime features in the same place. Add Upstash when you need caching, rate limits, or a queue next to your main database. The rest of this guide explains how to decide, what each one costs, and what to watch out for on Vercel.

First, how databases work with Vercel now

Vercel does not run its own database anymore. Vercel Postgres, which was built on Neon, and Vercel KV, which was built on Upstash, were moved over to those partners, and Vercel now offers databases through its Marketplace. Vercel's own documentation says marketplace storage integrations are available on all plans, that you can create resources from the Vercel dashboard, that credentials are added to your project as environment variables, and that billing can go through your Vercel account.

In practice, that means you pick a provider from the Marketplace, install it, and get connection details in your project without copying secrets by hand. You still have a separate company running your database, with its own limits, support, and pricing. Treat the Marketplace as a convenient way to connect, not as a single product with one set of rules.

How this comparison was made

This is an editorial comparison based on the providers' public pricing and documentation, checked in October 2026. I have not run benchmarks, so there are no speed numbers here. Plans and limits change often, so confirm anything that affects your budget on each provider's pricing page before you commit.

Quick comparison

Neon: plain Postgres that scales to zero

Neon is serverless Postgres. It separates storage from compute, scales compute up and down, and can suspend compute when a database is idle. Its pricing page lists three plans, Free, Launch, and Scale, where the paid plans are usage-based with no monthly minimum. The free plan has quotas per project, including 100 compute hours and 0.5 GB of storage, and compute suspends when the monthly limits are reached. Neon is now part of Databricks, which matters if vendor ownership is a factor for you.

What it does well on Vercel

• Branching. You can create a copy-on-write branch of your database in seconds, which makes it practical to give each preview deployment its own database. The Vercel integration can set this up, so check its settings.

• Scale to zero. A database that gets little traffic costs very little, which suits side projects, staging environments, and early products.

• Standard Postgres. Any library that speaks Postgres works, including common ORMs.

• A serverless driver. Neon provides a driver that connects over HTTP or WebSockets, which fits short-lived serverless functions.

What to watch out for

• Cold starts. When compute has been suspended, the first query after a quiet period takes a moment longer. For many apps this is fine. For a latency-sensitive production API, you may want to turn off scale to zero on a paid plan.

• Usage-based bills. A database that never sleeps costs more than one that does. Set autoscaling limits so a traffic spike does not surprise you.

• Postgres only. It does not include auth or file storage, so you add those separately.

Supabase: Postgres with a backend around it

Supabase gives you a Postgres database plus authentication, file storage, realtime subscriptions, edge functions, and auto-generated APIs. Its Free plan includes two active projects, 500 MB of database storage, and 50,000 monthly active users. Free projects pause after one week of inactivity. Pro costs $25 a month per organization and includes a $10 compute credit, and Team starts at $599 a month.

What it does well on Vercel

• One place for the backend. If you need user sign-in, file uploads, and a database, you can get all three without gluing separate services together.

• Row level security. Postgres policies let you control which rows each user can read or write, which suits apps that talk to the database directly from the client.

• Open source. The platform is built on open-source parts, which makes leaving easier than with some competitors.

• A good Free plan for MVPs. It is enough to build and test a real product.

What to watch out for

• The free pause. A free project that sits idle for a week gets paused. That is fine for a prototype and risky for anything customers depend on, so move to Pro before you launch publicly.

• Always-on compute. Supabase runs dedicated compute, so it does not scale to zero the way Neon does. Extra projects on Pro add compute cost.

• Big jumps between tiers. The step from Pro to Team is large, and it is mainly for compliance features, so plan for that if you need it.

• Connection handling. Serverless functions can open many short connections. Use the pooled connection string for your app, and keep the direct one for migrations.

Upstash: Redis for the fast, small jobs

Upstash is different. It is a serverless data platform whose main product is Redis, with related products for vectors, queues, workflows, and search. Redis keeps data in memory and is built for fast reads and writes of small items, which makes it a good fit for caching, sessions, rate limiting, and counters.

Upstash Redis has a free tier with 256 MB of data and 500,000 commands a month. Pay-as-you-go costs $0.20 per 100,000 commands plus storage beyond the first gigabyte, and fixed monthly plans start at $10 for steady, heavy usage. It works over normal Redis connections and also over an HTTP REST API, which suits serverless and edge runtimes where holding a long connection is awkward.

What it does well on Vercel

• Zero idle cost on pay-as-you-go. You pay for commands, so a quiet app costs almost nothing.

• HTTP access. It runs anywhere fetch works, including edge functions.

• Ready-made tools. Libraries exist for rate limiting and caching, so you do not have to build them.

What to watch out for

• It is not your main database. Redis holds data in memory and is not meant to replace Postgres for relational data like users, orders, and invoices.

• Per-command billing adds up. A busy app that makes many commands per request can cost more on pay-as-you-go than on a fixed plan, so check your numbers before you scale.

• Costs depend on how you use it. A loop that calls Redis dozens of times per page load is an easy way to waste money.

Here is a short example of rate limiting with Upstash. Use the environment variable names your integration adds, since they vary.

import { Ratelimit } from '@upstash/ratelimit';
import { Redis } from '@upstash/redis';

const redis = new Redis({
  url: process.env.YOUR_REDIS_REST_URL,
  token: process.env.YOUR_REDIS_REST_TOKEN,
});

const ratelimit = new Ratelimit({
  redis,
  limiter: Ratelimit.slidingWindow(10, '10 s'),
});

const { success } = await ratelimit.limit(userIp);
if (!success) return new Response('Too many requests', { status: 429 });

And a short example of querying Neon from a serverless function:

import { neon } from '@neondatabase/serverless';

const sql = neon(process.env.DATABASE_URL);
const users = await sqSELECT id, email FROM users LIMIT 10;

Things that matter on Vercel, whichever you pick

A few practical points apply to all three:

1. Match regions. Put your database in the same region as your Vercel functions, or set your functions to run near the database. Distance between the two adds delay to every query.

2. Mind your connections. Serverless functions start and stop often, so each can open its own connection. Use a pooled connection string or a serverless driver so you do not run out of connections under load.

3. Keep secrets in environment variables. Marketplace integrations add them for you. Do not commit connection strings.

4. Use separate databases for production and previews. Branching on Neon, or separate projects elsewhere, keeps test data away from real users.

5. Check limits before launch. Look at storage, connection, and request caps against your expected traffic, and set billing alerts where the provider offers them.

Which should you choose?

Work through these cases:

• You want the simplest Postgres and may use an ORM. Neon fits well, especially if preview databases appeal to you.

• You need sign-in, file uploads, and a database fast. Supabase saves you from stitching services together.

• You are building a prototype and want it free. Both Neon and Supabase have free plans. Remember the Supabase pause and the Neon cold start.

• You are launching to real customers. Move to a paid plan, since the free tier limits and pauses are not meant for production.

• You need rate limiting, caching, or a job queue. Add Upstash next to your main database.

• You are building an AI app with embeddings. Postgres can hold vectors with an extension, and Upstash also has a vector product, so compare what each gives you for your workload.

• You expect traffic that is spiky or low most of the time. Usage-based billing on Neon and Upstash tends to suit this better than always-on compute.

Example stacks

These are made-up examples to show how people combine them, not benchmarks:

• Solo SaaS MVP. Supabase for auth, database, and file storage, on the Free plan while you build, then Pro at launch.

• Next.js app with an ORM. Neon for Postgres, with a branch for each preview deployment.

• Public API with abuse risk. Neon or Supabase for data, plus Upstash for rate limiting.

• Content site with heavy reads. Postgres for content, Upstash as a cache in front of it.

Cost thinking for founders

Plan your costs in stages. In the prototype stage, free plans may cover you, so the real cost is the time you spend. At launch, expect to pay for always-on reliability, which means Supabase Pro or a paid Neon plan, plus a small Upstash bill if you use it. As you grow, watch the things that scale: compute hours on Neon, compute and egress on Supabase, and command counts on Upstash.

If you are cutting early costs, avoid running more databases than you need. Each extra project can add compute charges, and preview databases that never sleep can quietly raise your bill. A monthly look at your usage dashboards is enough to catch most surprises. If you want to compare notes with other builders, the best SaaS founder communities list and the SaaS community page are good places to ask what stacks people run in production.

A quick setup checklist

1. Install the integration from the Vercel Marketplace and confirm the environment variables it added to your project.

2. Choose a region close to your functions before you create any tables.

3. Use the pooled or serverless connection option in your app code.

4. Run migrations from your own machine or CI, using the direct connection where the provider recommends it.

5. Set billing or usage alerts, and write down which plan limits you are closest to.

6. Check how backups work, and test restoring one before you need it.

When to revisit your choice

Your first pick does not have to last forever. Look again when your free plan limits get close, when your monthly bill starts to move, when cold starts or pauses affect real users, or when you add features the current setup handles awkwardly, such as heavy file storage or realtime updates. A review every few months, with your usage numbers in front of you, is enough. Moving a Postgres database is much easier early on than after you have years of data, so do not wait until the move feels urgent.

Mistakes to avoid

• Treating Upstash as a replacement for Postgres. It solves a different problem.

• Launching on a free plan that pauses. Move to a paid plan before real users arrive.

• Ignoring connection limits. Serverless traffic can exhaust them quickly.

• Putting the database far from your functions. Latency adds up on every request.

• Skipping backups. Check what each plan includes, and keep your own export routine for important data.

• Choosing on price alone. Reliability, support, and how easy it is to leave matter too.

FAQ

What is the best database for Vercel? There is no single winner. Neon and Supabase are the usual choices for a main Postgres database, and Upstash is the usual add-on for caching and rate limiting. Pick based on whether you need auth and storage (Supabase) or plain serverless Postgres with branching (Neon).

Does Vercel have its own database? Not for Postgres or Redis. Vercel Postgres and Vercel KV were moved to Neon and Upstash, and Vercel now connects you to databases through its Marketplace.

Can I use Neon and Supabase together? You can, but most apps do not need two Postgres databases. Pick one for your main data, and add Upstash only if you need Redis features.

Is Neon or Supabase cheaper? It depends on how your app behaves. Neon can cost very little for a database that is idle most of the time. Supabase has a predictable base price on Pro. Compare them against your own traffic, not a generic example.

Can I move later? Both are Postgres, so moving between them is possible with a dump and restore, though auth and other Supabase features would need to be replaced. Test your migration on a copy before you rely on it.

Do I need Upstash at all? Only if you need fast key-value features, such as caching, rate limiting, or queues. Many early apps get by with Postgres alone.

Pick your main Postgres first, build with it on a free plan, and add Upstash only when a real need appears, like a rate limit or a slow query you want to cache. When you are ready to show what you built, you can submit your launch on Founders Today.