Vercel Postgres Options: What to Use Since the Switch

Vercel does not host databases. It hosts your functions and static assets superbly, and for everything stateful it connects you to someone else. 'Vercel Postgres' was Neon's infrastructure under a Vercel label from day one, and the pretence has since been dropped: Postgres on Vercel now lives in the Vercel Marketplace, provisioned from Neon directly and billed through your Vercel invoice. If you searched for Vercel Postgres hoping to add a database to a Next.js app, the real question is the one this article answers: which Postgres should sit behind a Vercel app, and what does Vercel-shaped traffic demand of it?

The one requirement that is not optional: pooling

Traditional servers open a handful of long-lived database connections. Serverless inverts that: every function instance may open its own connection, and a burst of traffic spawns hundreds of instances in seconds. Postgres tops out at a configured connection limit - often 20 to 100 on hosted plans - so a burst converts directly into

FATAL: sorry, too many clients already

The fix is a connection pooler between the functions and the database. Every serious option provides one - the only thing you must do is use the pooled connection string, not the direct one, and keep the client-side pool tiny:

// Use the POOLED string (port 6543 / -pooler suffix, provider-dependent)
import { Pool } from "pg";
​
const pool = new Pool({
  connectionString: process.env.DATABASE_URL, // pooled URL
  max: 1, // per function instance - the real pooling happens server-side
});

Option 1: Neon through the marketplace

The path of least resistance. Provisioning from Vercel's dashboard gives you a Neon database with the pooled string pre-wired into your project's environment variables, billing folded into Vercel, and preview-branch databases that pair naturally with Vercel preview deployments. The free tier covers prototypes comfortably. The economics are Neon's usage-based model - excellent while compute suspends between visits, and worth re-checking once traffic becomes steady, which we unpacked in our Neon pricing breakdown.

Option 2: Supabase

Supabase is the right call when the database was never the whole ask - when you also want auth, file storage and realtime subscriptions without building them. It connects to Vercel like any external Postgres (Supabase's pooler is built in; use the pooled string) and has its own Vercel integration for environment wiring. The $25 Pro floor and per-project compute meters are the trade - see our Supabase pricing analysis for where that lands at scale.

Option 3: external managed Postgres

Nothing about Vercel requires your database to come from its marketplace. A managed Postgres from anywhere - full disclosure, ours included - works identically: set the pooled connection string in Vercel's environment variables and deploy. What you gain is independence (your data host is not coupled to your app host's pricing decisions) and, with flat-priced providers, a bill that does not move with invocation counts. Swyftstack is $19/month flat with pooling and backups included; RDS and DigitalOcean play the same role with their own pricing shapes, compared in our PostgreSQL hosting guide.

The options side by side

Wiring it up: the details that bite

Whichever option you pick, the setup is the same three steps: set the pooled connection string as an environment variable in the Vercel project, reference it from your database client, and deploy. Two details reliably trip people up. First, migrations need the direct string, not the pooled one - schema-changing statements and advisory locks do not play well through a transaction-mode pooler, which is why Prisma's convention is two variables:

# .env - the split every provider recommends
DATABASE_URL="postgres://...-pooler.../<db>"   # runtime queries (pooled)
DIRECT_URL="postgres://.../<db>"               # migrations only (direct)

Second, remember that environment variables are per-environment on Vercel: production, preview and development each get their own values. Pointing preview deployments at the production database is the classic self-inflicted outage - give previews their own database or branch, which is exactly the workflow Neon's branching and Supabase's projects are built around.

Latency: put the database where the functions run

Vercel functions execute in a region (or several); every query crosses the distance between that region and your database. A function in Washington querying a database in Frankfurt adds ~90 ms to every round trip, and a typical page render makes several. Pick the database region to match your functions' primary region - it matters more than any performance feature on any provider's pricing page. If you use Vercel's edge runtime for latency-critical routes, keep those routes database-free or cache aggressively; the edge is global, your database is not.

What marketplace billing changes (and what it doesn't)

The marketplace's genuine convenience is consolidation: one invoice, one dashboard, environment variables injected automatically, and usage visible next to your Vercel spend. What it does not change is the underlying pricing - marketplace Neon bills at Neon's rates, so every observation in our pricing breakdown applies unchanged. It also does not change ownership questions: your data lives with the provider, and if you ever want to leave the marketplace arrangement, a standard pg_dump moves the database anywhere in an afternoon. Treat the marketplace as a checkout flow, not a platform commitment.

Choosing in three questions

• Is this a prototype? Marketplace Neon, free tier, done. Revisit when traffic is real.

• Do you need auth and file storage too? Supabase, and accept the platform gravity.

• Is traffic steady and the bill worth predicting? External flat-priced managed Postgres, same region as your functions.

Whichever you choose, the exit cost is one environment variable and one dump-and-restore. That is the quiet advantage of the marketplace era: since Vercel stopped pretending to host your database, your database decision stopped being a Vercel decision - it is an ordinary Postgres hosting decision, made with ordinary leverage, and reversible the ordinary way.

Prices quoted here were checked in July 2026. Vendors change them; treat the structure as the durable part and re-check the current numbers before you budget.