Every serverless Postgres vendor in 2026 has converged on the same headline pitch: "branch your database like you branch your Git repo." Neon said it first and said it loudest. Supabase bolted it onto its bundle. PlanetScale — the company that spent five years telling you MySQL/Vitess branching was structurally different from (and better than) whatever Postgres could do — now sells you Postgres branching too.
The pitch sounds identical across all three vendors. The bill does not. And that gap is the part nobody puts in a comparison table, because it requires actually reading the pricing docs instead of the marketing page above them.
Why this comparison matters right now
Three things collided in the last fifteen months to make "which serverless Postgres do I pick" a live decision instead of a settled one.
First, Databricks acquired Neon in May 2025 for a reported ~$1 billion — not to shut it down, but to fold its storage engine into a new product called Lakebase, aimed at agentic AI workloads. Databricks' own stated reason is the interesting part: they said roughly 80% of the databases being created on Neon were being provisioned by AI agents, not humans. That's not a rounding-error stat about a niche feature — it's a claim that ephemeral, machine-provisioned Postgres is already the majority use case for one of the category's biggest independent players, and it explains why an $80B data platform company wanted the technology badly enough to buy the whole team.
Second, PlanetScale — which built its entire identity on Vitess and MySQL — launched a managed Postgres product in private preview in July 2025 and took it to general availability that September. That's a company reversing a decade of positioning because the market decided branching-native Postgres, not MySQL sharding, is what developers actually want in 2026.
Third, pricing on all three platforms moved enough in the last year that any comparison written before mid-2025 is now wrong. Neon cut compute prices 15–25% and storage prices 80% after the Databricks deal. PlanetScale introduced a $5/month entry tier in October 2025 to compete on the low end again, a year after it had killed its free tier entirely. Supabase kept its plan prices flat but restructured how compute and branching get metered.
None of this is abstract for a working developer. If your team spins up a database branch per pull request — which is exactly the workflow all three vendors are selling — the architecture underneath "branching" determines whether that habit costs you nothing or costs you a second production bill.
It's also worth sitting with what "Lakebase" actually is, because it explains why Databricks paid what it paid rather than just building a competing storage engine. Databricks already had a data lakehouse — a system optimized for large-scale analytical queries over data sitting in cheap object storage. What it didn't have was a fast, transactional, branchable Postgres layer that agentic AI workflows could provision on demand to hold operational state — the kind of database an autonomous coding agent spins up to test a migration, or an AI application creates per-user-session and destroys minutes later. Neon's architecture, built from the ground up around cheap branching and scale-to-zero, was already solving exactly that problem for human developers running preview environments. Databricks' bet is that the same properties — instant, disposable, metadata-cheap databases — are about to become infrastructure that AI agents consume directly, at a volume no human developer workflow would ever generate on its own.
What each one actually does
Neon is the cleanest expression of "storage and compute are different problems." A Neon Postgres instance is a stateless compute node attached to a separate storage layer built from two components: a Pageserver that holds versioned page data, and Safekeepers that durably capture the write-ahead log before it's committed to storage. Because the storage layer is copy-on-write, creating a branch is a metadata operation — you get an isolated new Postgres endpoint pointing at a snapshot of the same underlying data pages, and only pages that diverge after the branch point consume new storage. Compute can also scale to zero when idle, and Neon exposes an HTTP driver so serverless/edge runtimes (Vercel Edge, Cloudflare Workers) can talk to it without holding a TCP connection open. The core engine is open source under Apache 2.0.
Supabase isn't really "a Postgres branching product" — it's a full backend-as-a-service built on top of vanilla managed Postgres, and branching is one line item in a much bigger bundle: auth, storage, auto-generated REST and GraphQL APIs, realtime subscriptions, edge functions, and a vector/embeddings toolkit for AI apps. If you want one vendor for your entire backend rather than a database plus five other SaaS bills, Supabase is built for that job specifically. Branching exists, but it's billed as a discrete hourly add-on rather than baked into the storage architecture the way Neon's is.
PlanetScale Postgres is architecturally the odd one out. Rather than separating storage and compute the way Neon does, PlanetScale's Postgres product uses Raft-based consensus with local NVMe storage per node — closer to a traditional highly-available cluster than a disaggregated serverless engine. Branches in PlanetScale aren't lightweight copy-on-write snapshots; each branch is its own dedicated cluster with its own compute and storage, billed independently and prorated to the millisecond. That's a deliberate tradeoff: you get real, isolated, production-grade infrastructure per branch (useful for load-testing against a schema change before it ships), at the cost of losing the "branches are basically free" story Neon tells.
How the branching workflow actually feels day to day
The marketing pages make all three sound like git checkout -b. In practice the workflow differs in ways that show up the first week you use each one, not just on the invoice.
Neon's branch creation is genuinely fast — seconds, not minutes — because it's a metadata pointer against existing storage rather than a provisioning event. Its GitHub integration creates and deletes a branch automatically per pull request, and its CLI (neonctl) and API make branch lifecycle scriptable enough that "ephemeral database per CI run" is a realistic default rather than an aspiration. The tradeoff is that you're relying on Neon's own schema-diff and reset tooling to manage what happens when a long-lived branch drifts from main; there's no separate migration-review workflow baked into the product the way PlanetScale built one.
PlanetScale, coming from its Vitess/MySQL background, built its identity around exactly that: a deploy request workflow where a schema change made on a branch goes through review before merging into production, with the platform handling the actual schema migration as a zero-downtime, non-locking operation. That heritage carries over to Postgres — the product is opinionated about schema change safety in a way Neon and Supabase aren't, because avoiding risky in-place migrations on production MySQL was Vitess's original reason for existing. If your team has been burned by a schema migration that locked a production table, PlanetScale's workflow is arguably the most mature of the three at preventing that specific failure — it's just that the price of that safety net is a branch that's a full cluster instead of a snapshot.
Supabase's branching is the newest of the three conceptually and layers on top of its existing project/dashboard model rather than being foundational to the storage engine. It integrates with GitHub similarly to Neon (branch per PR, with migrations applied via the Supabase CLI's declarative migration files), but because a Supabase branch is a full project-like environment with its own auth, storage, and edge function config — not just a Postgres snapshot — spinning one up is a heavier operation than Neon's and closer in spirit to PlanetScale's "this is basically a new environment" model, just billed by the hour instead of by cluster size.
Regions, latency, and where the data actually lives
All three run on the major public clouds, but the details of "where" affect both compliance and application latency in ways worth checking before committing. Neon and Supabase both publish region lists spanning AWS (and in Neon's case, Azure as well) across North America, Europe, and Asia-Pacific, with the caveat that Neon's compute/storage split means the two conceptually live in the same region but are still architecturally distinct services — worth checking against your own latency budget if you're doing anything chatty between compute and storage rather than a handful of round trips per request. PlanetScale's Postgres product, being newer, has a narrower region footprint at GA than either competitor, which matters directly for teams with data-residency requirements (EU customer data staying in EU regions, for instance) — a Postgres migration to PlanetScale is a much easier "yes" for a US-only startup than for a company that already has EU compliance commitments baked into its infrastructure.
None of the three vendors' marketing foregrounds region coverage the way they foreground branching speed or price-per-GB, which is exactly why it's worth checking directly against your own deployment footprint rather than assuming parity.
What changed vs. before
The single biggest structural change in this space is the Neon/Databricks deal, and it's worth being precise about what actually happened to pricing rather than repeating the marketing framing.
Before the acquisition, Neon's compute cost $0.14 per compute-unit-hour on its Launch tier and $0.26 on Scale. After Databricks folded Neon in, those dropped to $0.106 and $0.222 per CU-hour, and storage dropped from $1.75/GB to $0.35/GB — an 80% cut. Neon's own explanation is that running on "one of the world's largest multi-cloud infrastructures" (i.e., Databricks' negotiated AWS/Azure/GCP rates) let them pass savings through without touching margin. Vantage's analysis of this is worth taking seriously: AWS Enterprise Discount Programs scale with committed spend, and Databricks — which reportedly spends billions annually on cloud infrastructure directly and drives billions more through customer workloads — sits at a completely different point on that discount curve than pre-acquisition Neon ever could. In plain terms: the price cut is very likely a function of whose AWS contract Neon is now riding on, not a technical breakthrough in the storage engine. That matters for anyone building on Neon, because it means the price you're paying today is partly downstream of Databricks' negotiating leverage, not a fixed cost structure Neon controls independently. It's a good deal for you right now. Whether it's durable if Databricks' priorities shift toward folding Neon fully into Lakebase and away from a standalone low-margin SKU is a real open question, not a hypothetical.
PlanetScale moved in the opposite direction, twice. In late 2024 it killed its free tier entirely, repositioning as a premium, scale-focused product — a bet that free-tier users weren't the audience it wanted to keep serving. Then, having launched Postgres in 2025, it walked part of that back: on October 30, 2025, it introduced a Base plan starting at $5/month for a single-node, non-HA Postgres database aimed at development and non-critical workloads, alongside production 3-node HA clusters starting around $15/month. That's PlanetScale acknowledging that "premium only" cost it the exact developers who'd naturally graduate into paid production tiers later — a mistake plenty of platform vendors have made and unmade.
Supabase's changes were quieter but still consequential: it moved to organization-level billing where the plan subscription (Pro at $25/month) is separate from per-project compute, and it now bills database branching explicitly at $0.01344 per branch-hour — worth doing the arithmetic on, below.
Why developers should actually care
Cost modeling for the exact workflow being sold to you. All three vendors pitch "spin up a branch per PR for a real preview environment." The economics of doing that at scale are wildly different:
- On Neon, a branch is copy-on-write metadata against shared storage. If your CI creates and tears down a branch per PR and the PR doesn't touch much data, you're paying close to nothing beyond the compute time actually used, and compute can scale to zero between test runs.
- On Supabase, each active branch costs $0.01344/hour, which is trivial per-branch ($0.32/day) but adds up in a straightforward, linear way if you leave branches running instead of tearing them down — roughly $9.68/month per branch left on continuously, on top of its own compute.
- On PlanetScale, each branch is a full dedicated cluster. Spin up ten preview branches on the $15/month production HA tier and forget to tear them down, and you're carrying $150/month in idle infrastructure that looks, on your bill, exactly like ten small production databases — because architecturally, that's what they are.
None of these are wrong designs. But "instant branching" as a marketing phrase erases a real cost-model decision you're making by picking a vendor, and only one of the three (Neon) makes idle branches close to free by construction rather than by discipline.
Lock-in and exit cost. Neon's storage/compute engine is open source (Apache 2.0), which at minimum gives you a documented architecture and, in principle, a self-hosting path if you ever needed one — though the managed service's operational tooling isn't part of that. Supabase's client-facing stack (the dashboard, the various client libraries, the local CLI) is also largely open source, which matters if you're using Supabase for more than the database — auth and storage migrations are real work if you leave. PlanetScale's platform layer is proprietary; Vitess itself (the MySQL layer) is open source and CNCF-graduated, but the Postgres product's Raft/NVMe implementation is not something you can take with you.
Compliance and production readiness gating. Supabase gates SOC 2, ISO 27001, and HIPAA (as a paid add-on) behind its Team plan at $599/month — a real number to budget for the moment you have a healthcare or enterprise customer asking for a compliance questionnaire. Neon and PlanetScale both push equivalent guarantees behind custom Enterprise pricing rather than a published tier, which makes early cost comparison harder for a team that knows it'll need SOC 2 eventually but isn't there yet. If compliance timing matters to your roadmap, Supabase is at least the one platform where you can put a number on that milestone today instead of waiting for a sales call.
Backup and recovery posture as a hidden cost center. All three vendors treat point-in-time recovery as a premium feature rather than a default, but they charge for it differently enough to matter. Supabase prices PITR explicitly at $100/month per 7 days of retention — a number that scales linearly and predictably. PlanetScale bills backup storage per gigabyte ($0.023/GB) on top of whatever's included with your cluster tier, which is cheaper at small scale but harder to forecast as your data grows. Neon's backup retention is bundled differently across tiers rather than metered as a standalone line item. None of this shows up in the headline pricing page of any of the three vendors — it's the kind of cost you only discover when you go looking for "how do I restore to last Tuesday," which is exactly the wrong moment to be comparison-shopping.
Practical use cases per option
Neon fits best when: you're building preview-environment-per-PR CI workflows and want branch sprawl to not become a cost problem; you're deploying to edge/serverless runtimes and need the HTTP driver instead of a persistent TCP connection; or you're building AI agent tooling that provisions and destroys databases programmatically and needs that to be a cheap, fast, scale-to-zero operation — which, per Databricks' own numbers, is already the dominant real-world use case on the platform.
Supabase fits best when you want one vendor for the whole backend — Postgres plus auth plus storage plus realtime plus edge functions plus vector search for an AI feature — and you're willing to trade some Postgres purism for not having to integrate five services yourself. It's the strongest option for teams building a product from scratch who don't want a database vendor and an auth vendor and a storage vendor as three separate contracts and three separate on-call surfaces.
PlanetScale fits best when a branch needs to behave like a real, dedicated, production-shaped environment — load testing a migration against realistic concurrent connections and NVMe-backed I/O before it ships, or a team migrating off MySQL/Vitess that wants continuity with the same vendor and operational model while trying Postgres. It's a worse fit for high-branch-churn CI workflows unless you're disciplined about tearing branches down.
What the marketing pages don't say
Neon's pricing story leans hard on "no degradation in performance or margins" from the Databricks price cut. What it doesn't emphasize is that scale-to-zero has a real cost: cold starts. A Postgres instance that's been suspended takes measurable time to wake up on the next connection, which is a fine tradeoff for a PR preview branch nobody's hitting at 3am and a bad one for anything latency-sensitive that can't tolerate an occasional multi-hundred-millisecond wakeup penalty.
PlanetScale's "branching" pages describe the git-like workflow — create, test, merge, no table locks — in the same breezy tone Neon and Supabase use, without foregrounding that the unit of billing underneath is a full cluster. "Zero-downtime schema changes" is true and valuable; "branching is cheap" is not, and the two claims sit uncomfortably close together on the same page.
Supabase's $25/month Pro tier headline undersells what a real project costs. The plan includes a $10/month compute credit that covers exactly one Micro instance (2-core ARM, 1GB RAM, no dedicated resources) — genuinely small. A second project, or bumping to a Small/Medium instance for anything beyond a toy workload, adds its full cost on top with no credit applied. A two-project Pro org on Micro instances is $35/month before you've stored a meaningful amount of data or added point-in-time recovery ($100/month per 7 days of retention) or a custom domain ($10/month/project). The $25 number is real, but it's an entry price, not a working-team price.
Comparison table
| Dimension | Neon | Supabase | PlanetScale (Postgres) |
|---|---|---|---|
| Core architecture | Storage/compute separation, copy-on-write pages, Pageserver + Safekeepers | Standard managed Postgres + full BaaS layer on top | Raft consensus, local NVMe per node, dedicated cluster per branch |
| Branch cost model | Near-free (shared storage, metadata-level branch) | $0.01344/branch-hour (~$9.68/mo if always-on) | Full dedicated cluster per branch, from ~$15/mo (HA) |
| Entry price | Free tier; Launch $0.106/CU-hr compute | Free tier; Pro from $25/mo (+ compute add-ons) | Base plan from $5/mo (non-HA); HA from ~$15/mo |
| Storage price | $0.35/GB-month (post-Databricks cut) | $0.125/GB beyond 8GB included (General Purpose) | $0.50/GB beyond 10GB included |
| Scale-to-zero | Yes, native | No (compute runs continuously per project) | No (dedicated cluster per branch/environment) |
| Edge/serverless driver | Yes (HTTP driver) | Standard Postgres connection + pooler | Standard Postgres connection |
| Bundled services | None beyond Postgres | Auth, storage, realtime, edge functions, vector search | None beyond Postgres (Vitess/MySQL heritage) |
| Compliance tier gate | Custom Enterprise pricing | SOC2/ISO27001 at Team ($599/mo); HIPAA add-on | Custom Enterprise pricing |
| Core engine license | Open source (Apache 2.0) | Client/CLI layer largely open source | Proprietary platform (Vitess itself is open source) |
| 2025–26 defining change | Acquired by Databricks (~$1B, May 2025); compute -15–25%, storage -80% | Org-level billing restructure; explicit per-branch metering | Postgres GA (Sept 2025); Base plan reintroduced (Oct 2025) after killing free tier in 2024 |
An independent read
There's no version of this comparison where one platform is simply better. Neon's economics for branch-heavy workflows are genuinely the best of the three right now, but that pricing is downstream of Databricks' cloud contract, not a Neon-controlled cost structure, and a company that just spent a reported $1 billion to fold your storage engine into an internal product called Lakebase has priorities that may not permanently include subsidizing a cheap standalone developer SKU. Supabase is the safest choice for teams who want to buy a backend, not assemble one, and its pricing is at least legible even where it's not cheap. PlanetScale's Postgres bet is the newest and least proven of the three in production at scale, but the dedicated-cluster-per-branch model is a genuine, defensible choice for teams whose actual pain point is "our preview environments don't behave like production," not "our branches cost too much."
Pick based on your actual branch-churn pattern, not the demo. If you tear branches down aggressively in CI, Neon's model rewards that discipline financially in a way the other two don't. If you don't — if branches tend to linger because nobody owns cleanup — Supabase's linear per-hour fee is forgiving and PlanetScale's dedicated-cluster model will punish you the fastest.
Who should pick what
Solo developers and early-stage MVPs on a tight budget: start on Neon's or Supabase's free tier. Neither costs anything until you have real usage, and Neon's scale-to-zero means an app nobody's using yet effectively costs nothing to keep alive.
Teams building a full product from scratch who want one vendor for database, auth, storage, and realtime rather than integrating separate services: Supabase, budgeting realistically from the $35–100/month range once you're past a single toy project, not the $25 headline.
Platform and infra teams building AI agent tooling that provisions and tears down databases programmatically, or teams running CI with a database branch per PR and actual discipline about cleanup: Neon, with eyes open that today's Databricks-subsidized pricing is a current condition, not a permanent guarantee.
Teams whose preview environments need to behave like production — realistic concurrent load, dedicated I/O, testing a schema migration under real conditions before merge — and who are willing to pay per-branch for that fidelity, or who are already invested in PlanetScale's MySQL/Vitess ecosystem and want continuity: PlanetScale Postgres, with a hard rule about tearing down branches you're not actively using.
If your team already runs a database-branch-per-PR workflow on any of these three, the more useful audit than "which vendor is cheapest" is: how many branches are alive in your account right now that nobody's looked at in a week, and what is that actually costing you under your specific vendor's billing model?
Sources:
- Neon price drop likely just from Databricks AWS discounts (Vantage)
- PlanetScale Postgres pricing (official docs)
- Supabase Pricing (official)
- Neon vs Supabase 2026: $1B Deal, Scale-to-Zero (Tech Insider)
- Neon vs PlanetScale: Serverless MySQL vs Postgres (DB Pro Blog)
- Neon vs Supabase: Comparing Serverless Postgres (DB Pro Blog)
Top comments (0)