Pizzeria Bestek runs on Supabase. I picked it for the least glamorous reason there is: I needed a database and a login flow, plus somewhere to dump menu photos, all without opening three separate vendor dashboards mid-build. That call holds up fine for a single-tenant restaurant site. It would have been wrong for Callidus, where regulatory isolation mattered more than convenience, so that project ran on Firebase and Stripe Connect instead — no Supabase, no Postgres RLS anywhere near it. Same developer, same year, opposite database decision. Supabase, Neon, and Planetscale in 2026 aren't really competing for the same job. Most comparison posts write as if they are.
Key Takeaways
- Supabase bundles Postgres with auth, storage, realtime, and edge functions, so you get one dashboard instead of three, provided you're comfortable putting access control inside Postgres RLS policies.
- Neon is close to plain Postgres with branching and genuine scale-to-zero. Databricks paid roughly $1 billion for it in 2025, largely because AI agents were already provisioning most of its databases automatically.
- Planetscale added real Postgres support in September 2025 without retiring its original MySQL and Vitess platform, so the name now covers two different products depending on which sales page you land on.
- A misconfigured RLS policy is one of the most common ways a solo-built app leaks another user's data. CVE-2025-48757 found it in over 10% of the production apps a researcher actually scanned.
- Picking among these three has less to do with raw database quality than with where you want the line between your app and your infrastructure to sit.
Do You Actually Need Supabase's Bundle, or Just Postgres?
You need Supabase's bundle only when you want one login system and one storage layer running on Postgres, governed by a single RLS policy language.
Pizzeria Bestek is the case for the bundle. It's a small build with one deploy target: a Supabase project handling auth, the Postgres database, the image bucket for menu photos, and the realtime updates on the kitchen order queue, wired up the way I documented in pairing React with Supabase's row-level security. What Supabase actually is underneath the marketing is a hosted Postgres instance with an API layer, an auth service, and a storage bucket bolted on. See what Supabase bundles versus what you'd otherwise assemble yourself for the full breakdown. That bundle is the whole pitch, and it's a genuinely good one for a small team that doesn't want a second vendor for login.
It's also the part people get wrong most often. The common failure mode is writing a policy against auth.role() = 'authenticated' instead of auth.uid() = user_id, which quietly lets every logged-in user read every other user's rows. Security researcher Matt Palmer's CVE-2025-48757 disclosure scanned 1,645 Lovable-generated apps and found 170 of them (10.3%) shipping tables an anonymous API key could read directly, no session required. It's rarely a security team that catches this first. More often it's a support ticket on a random Tuesday morning, a customer asking why someone else's order confirmation showed up in their history, and the answer turns out to be a policy nobody re-read since the day it was written. Ask yourself honestly: when did you last read your own RLS policies end to end, instead of trusting they still say what you wrote six months ago?
If your team already thinks in Postgres and doesn't want a second identity provider, the bundle earns its price. If you've already got Clerk or Auth0 wired in, you're paying for half a platform you'll never touch.
Why Did Databricks Pay Roughly $1 Billion for Neon in 2025?
Databricks bought Neon to get serverless Postgres that AI agents could provision on their own, in under a second, without waiting on a human.
Neon is the closest of the three to plain Postgres with extras layered on top: real branching, copy-on-write, so a feature branch gets its own database instance in seconds, and scale-to-zero that actually suspends compute after idle time instead of just marketing the phrase. Databricks announced the acquisition in May 2025 at a price reported around $1 billion, and its own materials were unusually candid about why: over 80% of the databases provisioned on Neon were being created automatically by AI agents rather than by humans. Not people clicking "new project." Software, deciding it needed a database, and getting one in under half a second.
That statistic is the whole thesis of the deal, and it changes what "compute pricing" even means once you sit with it. A CU-hour on Neon (0.25 CU for four hours is one CU-hour, on their own math) only accrues while the database is awake. Post-acquisition, Neon cut compute pricing by 15-25% across its Launch and Scale tiers. I assumed at first that was Neon getting more efficient post-deal. It's more likely just Databricks' enterprise-scale AWS discounts flowing downhill after Neon's infrastructure consolidated into Databricks' cloud account, which matters if you're deciding whether the current pricing is durable or an acquisition-week honeymoon rate. If your workload spikes and idles unpredictably (a demo environment, a preview deploy per pull request, a genuinely agentic backend), that pricing model is built for you. If your database runs hot around the clock, scale-to-zero buys you nothing, and you're just paying Neon's compute rate for a database that never actually scales to zero.
Planetscale Kept MySQL. It Just Added Postgres, Too
Planetscale did not pivot from MySQL to Postgres, whatever the headlines about "Planetscale goes Postgres" implied when they ran in late 2025. It shipped a second, separate Postgres product in September 2025 and kept running the original Vitess-based MySQL platform underneath customers like Cursor, Intercom, and Block.
That distinction matters because it erases the actual advantage the MySQL side still has: non-blocking schema changes, powered by Vitess, the same sharding layer that runs YouTube's MySQL fleet. Adding a column to a hundred-million-row table without locking it is a real operational win that Postgres still doesn't match natively. Teams with existing MySQL data have no reason to abandon it for a rewrite just because Postgres is having a moment this year. The new Postgres product is a different animal: single-node databases start at $5 a month, a sharp turn from the MySQL side's $39 minimum with no free tier since 2024, built on Planetscale's own Metal infrastructure with a from-scratch sharding layer called Neki still being built out. Choosing Planetscale in 2026 means choosing which of two products you actually want, not picking one company.
Not About Which Engine Is Faster
The engine speed argument barely matters here. Postgres and MySQL under real production load, tuned properly, land close enough that it shouldn't decide anything on its own. What actually separates these three is which failure mode each vendor already owns for you before you've even shipped.
Supabase vs Neon vs Planetscale at a Glance
| | Supabase | Neon | Planetscale (Postgres) | |---|---|---|---| | Core model | Postgres + auth + storage + realtime | Standalone serverless Postgres | Postgres on Planetscale's Metal infra | | Best for | Teams that want one vendor, not three | Branching-heavy workflows, spiky or agentic traffic | Teams already committed to Planetscale's ops model | | Free tier | 500 MB, pauses after 1 week idle | 100 CU-hours, 0.5 GB storage, 5-min suspend | None on MySQL side; Postgres starts at $5/mo | | Entry paid price | $25/mo (Pro) | Pay-as-you-go from ~$0.106/CU-hour | $5/mo single-node, no HA | | Branching | $0.01344 per branch-hour | 10-25 branches included, then $1.50/branch-month | Not the headline feature here | | Scale-to-zero | Not the model, always-on compute billed per project | Core feature, suspends after configurable idle window | No, nothing sleeps by design |
How I'd Actually Decide
- Name the actual fear before you compare feature lists: a second login vendor to manage, or a compute bill that spikes without warning. That fear decides more of this than any benchmark will.
- If you want one dashboard for auth, storage, and the database, default to Supabase, and budget real time to read your own RLS policies, not just write them once and move on.
- If your traffic is spiky, agentic, or mostly idle between bursts, default to Neon and treat branching as a feature you'll actually use in CI, not a nice-to-have on a pricing page.
- If you're already running MySQL in production, don't switch to Postgres just because it's the trendier engine this year. Planetscale's non-blocking schema changes on Vitess are a real reason to stay put, and if you're at the scale where horizontal sharding stops being optional, Vitess is the one platform of these three built from the start for exactly that. For Postgres that same capability is still forthcoming rather than shipped: Planetscale's Postgres sharding system, a project called Neki, is in early access rather than general availability, so weigh it as a roadmap signal for large or fast-growing workloads, not a production box you can tick today.
- Whichever you pick, if you're touching it through Prisma, watch the connection-pooling gotcha. A fresh
PrismaClientper serverless invocation exhausts your pool fast, which is exactly the failure mode a proper Next.js and Postgres setup is meant to prevent, and it bites scale-to-zero databases hardest, because every cold start looks like a fresh connection storm to the pool.
None of these three vendors are running a different database under the hood. Postgres is Postgres whether Supabase, Neon, or Planetscale's new offering is holding the connection string. The difference sits entirely in what's wrapped around it, and in how honestly that wrapper's pricing model matches your actual traffic shape. If you haven't locked the rest of your stack yet, the SaaS stack choices that hold up under real production load is a reasonable place to sanity-check the database pick against everything else you're about to commit to.
Go pull up last month's bill from whichever of these three you're on, and check whether you're paying for compute you actually used, or for a platform you only ever touch through its dashboard.