Choosing Between Supabase, Neon, and Planetscale in 2026

You need a Postgres database for a SaaS product and three vendors keep showing up: Supabase, Neon and Planetscale. They don't compete for quite the same job, and the pricing pages changed enough since the first version of this post that I re-checked every number on the vendors' own pages on 30 September 2026. Your first action: write down whether you need a login system and file storage from the database vendor, or only a Postgres connection string. That single answer removes one of the three options for most teams.

Supabase vs Neon vs Planetscale: Which Postgres Fits Your SaaS?

Pick Supabase if you want Postgres bundled with auth and storage, Neon if you want plain serverless Postgres with branching and scale-to-zero, and Planetscale if you want its Postgres product or its long-running Vitess MySQL platform.

The table below uses only numbers from each vendor's pricing page, fetched on 30 September 2026. Prices and limits change often, so treat it as a snapshot and re-check before you commit.

Sources: Supabase pricing, Neon pricing, Planetscale pricing. The Neon Launch and Scale plans state no monthly minimum, and Neon notes that invoices under $0.50 are not collected.

Do You Need Supabase's Bundle, or Just Postgres?

You need the bundle when one vendor should own your database, login and file storage, and you're comfortable expressing access control as Row Level Security policies inside Postgres.

Pizzeria Bestek is my example of the bundle working for a small build. Its case study lists React on the front end, Supabase Postgres with Row Level Security on all tables, and three Supabase Edge Functions orchestrating the admin flow. The restaurant owns the Supabase account after handover. That's a single-tenant site with one deploy target, which is the situation the bundle suits.

Callidus went the other way. It's a multi-tenant clinic platform built on React, Firebase and Stripe Connect, with per-clinic isolation as a core requirement, so I chose Firestore security rules instead of Postgres policies. If you're weighing exactly that trade-off, Firestore rules versus Postgres RLS for multi-tenant SaaS compares them, and Supabase versus Firebase covers the vendor-level choice.

Why do RLS mistakes cause data leaks?

Because a table in an exposed schema without RLS is readable and writable by any role with a grant on it, and the Supabase RLS guide says adding policies doesn't take those grants back. The same page warns that auth.uid() returns null when no user is authenticated, so a policy comparing it to a column can silently misbehave. It recommends an explicit auth.uid() IS NOT NULL AND auth.uid() = user_id check and tests under supabase/tests/ that cover both allowed and denied operations for each role.

The public record shows the risk is real. The National Vulnerability Database entry for CVE-2025-48757, published in May 2025, describes an insufficient Row-Level Security policy in Lovable, through 2025-04-15, that let remote unauthenticated attackers read or write arbitrary tables of generated sites. The entry also notes the supplier disputes the framing, arguing each customer is responsible for protecting their own application's data. Read it as a warning about policies nobody re-read, not as a verdict on Postgres.

If you already run Clerk or Auth0, you'd be paying for half a platform you won't use. And if you plan to keep RLS as your only tenant boundary, my multi-tenant Supabase RLS walkthrough is the longer version.

What Does Neon's Scale-to-Zero Mean for Your Bill?

Neon bills compute by the CU-hour and suspends idle compute, so spiky or mostly idle workloads cost less than a database that runs hot all day.

Neon's branching documentation describes branches as copy-on-write clones where writes are saved as a delta, and says creating a branch doesn't increase load on the parent. That makes a database per pull request or per preview deploy practical. Databricks announced its agreement to acquire Neon on 14 May 2025, and the announcement states that over 80% of the databases provisioned on Neon were created automatically by AI agents rather than by humans. It also says instances can spin up in 500 milliseconds or less. The announcement did not disclose a purchase price, so I've dropped the figure I'd previously repeated from secondary coverage.

This suggests Neon's model was built for exactly the "database on demand" pattern, but it's an inference, not a claim from either company. For cost, the pricing page gives you the levers: on the Free plan scale-to-zero after 5 minutes can't be disabled, on Launch it can be turned off, and on Scale you can configure anything from 1 minute to always on. If your primary database must never pause, that points you to a paid plan with suspension disabled, and to connection pooling that copes with serverless cold starts.

What might the compute bill look like for a spiky workload?

Here's a hypothetical to make the pricing concrete, using only the Neon rates from the table and simple arithmetic. Suppose a staging database runs at 1 CU for four hours a day. That's about 120 CU-hours a month, which at $0.106 per CU-hour comes to roughly $12.72 of compute, and the Free plan's 100 CU-hours per project would already cover most of it. Now suppose a production database runs at 1 CU around the clock: about 730 hours, or roughly $77 of compute at the same rate, before storage at $0.35 per GB-month. Compare that with Supabase Pro at $25 a month, which includes $10 of compute credits covering one project on Micro compute, and a Micro add-on at $10.

These figures are illustrations, not quotes. They ignore storage, egress, plan-level features and the fact that real workloads autoscale, so use them only to see which pricing shape matches your traffic. A database that's busy all day gains nothing from suspension, while one that idles most of the day gains a lot. If you can't say which describes yours, look at a week of real usage before you choose.

Did Planetscale Move From MySQL to Postgres?

No. Planetscale added Postgres as a second product, generally available since 22 September 2025, and its own announcement says the managed Vitess product continues.

The general availability post says Planetscale has served companies such as Cursor, Intercom and Block on Vitess for five years and that Postgres starts at $5 a month. The pricing page confirms two price ladders: a Postgres single node from $5 a month and a three-node HA setup from $15, against Vitess from $39 a month. It also lists Metal options for both. On sharding, the Neki page now says sharded Postgres "is now available", which replaces the early-access wording I used earlier. If you have existing MySQL data, that's a reason to stay on the MySQL product rather than rewrite for a trend. If you're starting fresh on Postgres, you're comparing it against Neon and Supabase on cost, ops model and branching, not on engine speed.

What about migration paths between the three?

The safest assumption is that your data moves and your surrounding services don't. Between Supabase and Neon, both are Postgres, so schema and SQL travel, but Supabase Auth, Storage and Edge Functions need replacements if you leave the bundle. Between Planetscale's MySQL and Postgres products, you're changing SQL dialects, which is a rewrite of queries and possibly of your ORM configuration. I haven't run a migration between these vendors for this post, so I'm giving the shape of the work, not a timeline. Rehearse on a copy of your data before you commit.

How I'd decide

1. Name your actual constraint: a second login vendor to manage, or a compute bill that spikes without warning.
2. If you want one dashboard for auth, storage and database, start with Supabase, and schedule time to re-read your policies.
3. If traffic is spiky or idle between bursts, start with Neon and use branches in CI.
4. If you already run MySQL in production, look at Planetscale's Vitess product before rewriting anything.
5. Whichever you choose, it's still PostgreSQL or MySQL underneath, so test your migration path early. The SaaS MVP stack guide is a good place to check the database against the rest of your choices.

Here's your next step: open last month's invoice from whichever vendor you use and compare what you paid for compute against what your app actually used.