Vercel Postgres is a Neon resell. Neon’s own enterprise documentation confirms this directly, listing it alongside Replit and RetoolDB as products built on the Neon platform. The “bundled database” marketed to Next.js teams is not an independent Postgres engine; it’s Neon with Vercel’s billing layer on top. Since Neon became a Databricks company in May 2025, the vendor count for any team using Vercel Postgres is three (Vercel, Neon, Databricks), where most teams assume there is one.
What is Vercel Postgres, technically?
Vercel Postgres is a branded interface to Neon’s managed Postgres service. Neon’s enterprise documentation lists it as one of the top products built on the Neon platform. The architecture is a resell arrangement: Neon operates the Postgres clusters, Neon’s connection pooler handles serverless connection management, and Vercel wraps it in a familiar dashboard with environment variables pre-provisioned into your project.
Both Vercel’s infrastructure and Neon run on Amazon Web Services. Neon is available on AWS and Azure but not yet on Google Cloud. That AWS overlap is the factual basis for claims about “in-network” connection routing between Vercel functions and Vercel Postgres: compute and database share the same underlying cloud provider, which reduces cross-network egress potential. Whether Vercel configures that routing through specific VPC peering or private networking is not confirmed in publicly available documentation; the co-location benefit is architecturally plausible, but its extent is implementation-dependent.
What Vercel adds over going directly to Neon: automated environment variable injection (DATABASE_URL pre-populated without manual setup), billing consolidated onto a single Vercel invoice, and dashboard visibility into query metrics. These are real workflow benefits for small teams. Query latency, connection limits, and Postgres version support are all determined by the Neon layer beneath, not by Vercel’s wrapper.
What does the Databricks acquisition change?
Neon was acquired by Databricks in May 2025, moving from independent startup to business unit inside one of the largest data-warehouse companies. This matters most for teams choosing Vercel Postgres specifically as a vendor consolidation play.
The pitch for bundled databases is simpler contracts: one vendor, one invoice, one support channel. Vercel Postgres delivers that at the Vercel layer. The underlying Postgres engine is now governed by a company with its own roadmap priorities and enterprise sales motion. Teams using Vercel Postgres have one vendor relationship (with Vercel) and are implicitly depending on two more (Neon and Databricks), neither of which they have a direct contract with.
This does not automatically disqualify the product. Databricks has clear incentives to keep Neon healthy; it’s the developer entry point Databricks wants to own as it expands beyond the data engineering market. But the independence assumption is gone, and the product’s trajectory is now set by a company whose primary customers are data engineers running Spark jobs, not Next.js teams shipping web applications.
Neon holds SOC 2, ISO 27001, ISO 27701, GDPR, CCPA, and HIPAA certifications, and offers a 99.95% uptime SLA at the enterprise tier. Those certifications cover the layer Neon operates. Your contractual coverage runs through Vercel, not through the entity holding the certifications.
How does connection pooling differ across these options?
Neon’s pooler, which Vercel Postgres inherits, addresses the serverless connection problem that makes traditional managed Postgres painful in function environments. A standard Postgres server holds one connection open per client; a serverless function that fires hundreds of times per second creates hundreds of connections and exhausts the pool. Neon’s architecture is built around this constraint, claiming 10,000+ connections with no timeouts, a vendor-stated figure, not an independently benchmarked one.
Vercel’s Fluid Compute, introduced in 2025, shifts the picture somewhat. It allows a single function instance to handle multiple concurrent requests rather than spawning a new instance per invocation, which reduces the connection burst. The pooling implementation underneath is still Neon’s. Going directly to Neon gives you the identical pooler with a different billing arrangement and a direct support relationship instead of Vercel acting as intermediary.
Neon also offers scale-to-zero for inactive databases and vendor-stated sub-second provisioning for new instances. Scale-to-zero is useful for development and staging environments that sit idle for long stretches. For production with consistent traffic, the cold-start latency warrants measuring against actual p99 requirements before committing.
Supabase uses PgBouncer as its default pooler, with Supavisor as an alternative for higher concurrency. That’s a different architecture with different tradeoffs at high connection counts, but a direct comparison of pooler behavior requires consulting current Supabase documentation, the specifics aren’t covered by the sources available for this article.
What do the pricing tiers actually look like?
The sources used for this article do not confirm specific Vercel Postgres pricing tiers, per-plan connection limits, or GA status for Hobby and Pro tiers as of publication. Pricing for all three options changes faster than editorial cycles, so citing specific plan figures here would likely be stale by the time a reader acts on them. What the architecture implies is more durable.
When you use Vercel Postgres, you pay for Neon’s infrastructure with a Vercel margin on top. Going directly to Neon removes that margin. How large the margin is, and whether it’s offset by setup savings from integration, depends on your usage profile. Teams with low storage and minimal compute, typical for early-stage projects, may find the convenience worth a premium. Teams with significant write volume and multiple production environments will want to compare current Neon direct pricing before committing.
Supabase’s pricing structure differs at the architecture level: it bundles database compute, storage, bandwidth, Auth, Storage, and real-time features into a single platform. Comparing it line-by-line with a pure Postgres-as-a-service option requires mapping which Supabase features your application actually uses, which makes the math more involved than a storage-plus-compute comparison with Neon.
How hard is it to migrate out?
Getting your data out of Vercel Postgres is a standard pg_dump operation. There is no proprietary storage format. What complicates migration is the operational layer: Vercel environment variables, Vercel’s serverless client library (@vercel/postgres), and any Vercel-specific connection string format embedded in your codebase create friction when switching providers. This is not lock-in by accident.
Moving from Vercel Postgres to Neon direct is the lowest-friction path. Same engine, same pooler, same Databricks ownership underneath. You change the billing arrangement and gain a direct contractual relationship; the schema, the data, and the connection pooling behavior are all compatible.
Supabase is a harder migration not because of data format but because of scope. If you’ve adopted Supabase-specific surfaces (Row Level Security policies built around Supabase Auth, real-time subscriptions, the Supabase SDK), those components don’t transfer. The data moves via pg_dump; the operational layer doesn’t.
When does the bundled database actually win?
The bundled database wins when setup cost is the dominant variable. For a solo developer or small team shipping a Next.js application on Vercel, zero-configuration DATABASE_URL and single-dashboard billing save real hours. When your team is small and your monthly database spend is in the tens of dollars, vendor count and lock-in are theoretical concerns that don’t affect daily decisions.
The calculus changes at three inflection points.
When you leave Vercel’s compute. If your backend shifts to a different cloud or a self-hosted environment, the in-network co-location benefit disappears and the Vercel billing wrapper becomes pure overhead. Going directly to Neon at that point is strictly better.
When database spend becomes a line item. The Neon resell margin compounds as usage grows. Run the direct comparison against neon.tech’s current pricing at the first billing review where Postgres costs are visible in budget discussions, not after your codebase has absorbed Vercel’s client library throughout.
When ownership trajectory matters. Vercel raised $300 million at a $9.3 billion valuation in September 2025. Databricks operates at a different scale with different strategic priorities. Teams planning on this stack for a multi-year horizon should track Databricks’ roadmap for Neon as the signal for where the database is actually headed, independent of what Vercel’s product pages say.
For teams that need Postgres plus adjacent services (Auth, Storage, real-time), Supabase is the correct frame of reference rather than a variation on Neon. The three options are not equivalent competitors: Vercel Postgres and Neon direct are close substitutes separated by a billing layer, while Supabase is a different product scope entirely.
The honest framing: Vercel Postgres is Neon with Vercel convenience, now with Databricks as a silent third party. The convenience is real. So is the vendor count.
Frequently Asked Questions
Does the bundled DB still make sense if my compute runs on Google Cloud?
Less so. The in-network co-location benefit assumes both compute and database sit on the same cloud, and Vercel’s infrastructure runs on AWS. A GCP-hosted backend pays cross-cloud egress on every query and adds latency that erodes the integration advantage, making a GCP-native option like Cloud SQL or AlloyDB the stronger fit.
How should I weigh Neon’s advertised 80% cost-savings claim?
The 80% figure and the 10x capacity reduction come from Neon’s own enterprise marketing with no independent benchmark cited, so treat them as ceiling claims rather than measured results. They most plausibly reflect a comparison against overprovisioned managed Postgres where scale-to-zero wipes out idle spend, not a head-to-head against an already-tuned serverless setup.
What distinguishes Supabase’s PgBouncer pooler from Supavisor?
PgBouncer is a long-established, process-based pooler with proven reliability but limits on per-instance connection ceilings. Supavisor is a newer Elixir-based pooler Supabase built for multi-tenant isolation and higher concurrency across shared infrastructure. Teams approaching PgBouncer’s per-instance ceiling are the ones who need to switch.
What would signal that Databricks is steering Neon away from web-app workloads?
Watch Databricks earnings calls and product launches for Neon repositioning toward the Lakehouse, and any pricing shift that favors analytics over transactional workloads. Neon reports 12 million Postgres databases started daily on its platform, which gives Databricks a strong reason to keep the developer surface intact, but a strategic pivot would surface in pricing or feature deprecation before marketing copy changes.
Can I escalate directly to Neon while using Vercel Postgres?
Not through the Vercel relationship. Neon’s 24/7 priority support and 99.95% enterprise SLA are attached to Neon’s own contracts, so a team that needs direct escalation to the database operator has to sign with Neon separately or migrate off the Vercel wrapper. Incident routing runs through Vercel’s support channel first, which adds a hop for any issue rooted in the Neon layer.
