Neon vs Supabase vs PlanetScale in 2025 — the managed-Postgres-and-friends decision

Three platforms eating Heroku Postgres”s lunch through 2024-2025. Each one optimizes for a fundamentally different jobs-to-be-done, and Theo”s July 4 video — “I finally switched to Postgres” — captured the broader “consolidate to durable, boring infrastructure” sentiment that”s shaped how engineers thought about database choice in 2025.

The community sentiment landed in concrete terms. The r/Supabase “I chose Supabase as tech stack. Now my client wants to sue me.” thread (322 upvotes, June 11) — the kind of story you don”t want to be in but you should read to avoid — exemplifies why the platform-choice matters more than benchmark performance. The wrong platform for the wrong workload doesn”t just slow you down; it creates client-trust problems that survive the technical fix.

This is the working comparison from running apps on all three across 2024-2025.

What each platform actually is

Neon (neon.com): Serverless Postgres with branching. Each “branch” is a near-instant copy of your database (copy-on-write). Generous free tier; auto-scaling compute; designed for Vercel-adjacent deployment patterns. Postgres only.

Supabase (supabase.com): Postgres + auth + realtime + storage + edge functions, packaged as a “Firebase alternative for Postgres.” Built-in admin UI. Generous free tier; clear paid tiers. Postgres only.

PlanetScale (planetscale.com): Originally Vitess-on-MySQL; now also supports Postgres. Branch-based workflow with schema migrations as first-class. Built for high-scale OLTP. No free tier (since April 2024 elimination).

The decision matrix

Pick Neon if:

• You want pure Postgres without bundled extras
• Branching workflow (per-PR database copies) matters to you
• You”re Vercel-deployed and want tight integration
• Cost-sensitive at small-to-medium scale
• You don”t need auth / realtime / storage in the database layer

Pick Supabase if:

• You want a Firebase-shaped DX with Postgres underneath
• Built-in auth / realtime / storage save you time
• You”re building an MVP and want to ship faster
• The admin UI is valuable for your team
• You can manage Row Level Security (RLS) discipline

Pick PlanetScale if:

• You need MySQL-compatibility specifically (Vitess heritage)
• You”re at high enough scale that branching + safe migrations matter operationally
• You can absorb the paid-tier minimum
• You value the operational maturity that comes with no-free-tier focus

Don”t pick any if:

• You”re already on RDS / Cloud SQL / AlloyDB and it works
• You need exotic Postgres extensions not supported by managed providers
• Your scale is small enough that self-hosted Postgres on a Hetzner CCX23 is cheaper and sufficient

The Supabase “client wants to sue me” lesson

The 322-upvote thread details a real consulting nightmare. OP built a custom platform on Supabase; non-technical clients got influenced by another founder who claimed Supabase was unreliable; threatened to sue.

Top response (81 upvotes):

“AFAIK supabase runs on aws. While amazon rds doesn”t support community extensions like vector, supabase does (if you”re using some of these kind of extensions…)”

The substantive defense of Supabase: it”s real infrastructure (AWS-backed), with capability advantages (pgvector, edge functions, realtime). The client”s “Supabase is bad” claim was usually wrong on the merits.

The actionable lesson: the platform choice creates trust implications beyond the technical decision. For consultant / agency work, picking the “well-known boring” option (RDS for Postgres) sometimes wins on client-comfort even when better technical options exist. For solo / small-team work, this matters less.

The Supabase RLS pain point

The r/Supabase “RLS are a pain” thread (83 upvotes, July 14) captures the real friction Supabase users hit. Row Level Security is Postgres”s native authorization mechanism; Supabase makes it central to how multi-tenant apps work; RLS is genuinely hard to get right and easy to leak data with.

The recurring Supabase failure mode: vibe-coded RLS policies that look right but have edge cases that leak data. This is the canonical Supabase risk — the platform makes it easy to ship; the security model requires discipline most users underestimate.

For engineers committed to Supabase: invest heavily in RLS testing. For engineers not committed: consider whether Supabase”s RLS-centric model fits your team”s security discipline.

Theo”s “switched to Postgres” framing

Theo”s July 4 video captures the broader 2025 pattern: engineers consolidating their stacks to fewer, more boring choices. Postgres + a managed provider (one of these three, or RDS) is the consolidation default for new SaaS apps.

The implication for the three-way comparison: the “which managed Postgres” question matters less than “managed Postgres at all.” All three platforms are good enough that most teams shipping new apps in 2025 would be fine with any of them. The choice is values-driven and team-fit-driven, not “this one is dramatically better.”

Theo”s parallel “Vercel Finally Caught Up” (Jun 27) and Vercel-Nuxt hires (Jul 17) cover the broader platform-decision context. Database choice is downstream of platform choice — Vercel users tend toward Neon; Cloudflare users tend toward D1 (covered in the D1 read replicas article); custom-infrastructure users tend toward RDS or one of the three.

The “Making Postgres 42,000x slower” signal

The r/programming 1,857-upvote thread (Jul 27) is unrelated to managed-Postgres choice specifically, but it”s a useful reminder: Postgres performance is mostly about how you use it, not which managed provider hosts it. Bad query patterns kill performance regardless of platform. Good query patterns scale fine on any of the three.

The corollary: invest in Postgres expertise more than platform shopping. Time spent learning EXPLAIN ANALYZE, index strategies, and connection pooling pays back across whichever platform you end up on.

The 2025 nextjs / MVP stack signal

The r/nextjs “My MVP tech stack for 2025” thread (120 upvotes, Jul 2) — and the broader “best place to host Next.js with Postgres” discourse — shows the working pattern most teams converge on:

• Next.js / TanStack Start / Astro for frontend
• Hosted Postgres (one of these three) for primary data
• Cloudflare R2 / Vercel Blob / Supabase Storage for file storage
• Resend / Postmark for email
• Stripe for payments
• Sentry / Highlight / Posthog for monitoring

For new builds in mid-2025, the database choice is one element of a stack that”s broadly converged. Pick the option that fits your other stack decisions.

Performance and pricing (honest version)

For small apps (< 1GB data, < 100 GB egress / month):

• All three have free tiers or low-cost plans that work
• Performance differences don”t matter
• Pick based on developer experience

For medium apps (1-50 GB data, 1-10 TB egress / month):

• Neon: ~$50-200/mo depending on compute
• Supabase: ~$25-150/mo (Pro tier + scaling)
• PlanetScale: ~$150-500/mo (no free tier; entry is paid)
• Performance comparable across all three for typical Postgres workloads

For large apps (50+ GB, high QPS):

• Math shifts toward PlanetScale for high-write workloads (Vitess heritage)
• Neon for read-replica patterns (their architecture matches)
• Self-hosted Postgres on dedicated infrastructure becomes cost-competitive

Creator POV vs Reddit dissent

Theo”s POV through 2025 emphasizes platform-consolidation — pick fewer, deeper tools. Postgres + a managed provider matches.

The Reddit dissent splits productively:

The “Supabase for everything” camp — accurate for MVP-stage teams. The all-in-one DX is real.

The “Neon if you”re Vercel-deployed” camp — accurate for that specific stack. Tight integration matters.

The “PlanetScale lost its way” camp — present, partly true. The April 2024 free-tier elimination cost PlanetScale a lot of mindshare. The product is still excellent; market position is weaker.

The “just use RDS” camp — pragmatic, valid for AWS-heavy organizations. Less developer-experience polish; more operational maturity.

The “self-host Postgres on a VPS” camp — gaining ground with the Render + Hetzner + Coolify pattern. For cost-sensitive small teams, the math works.

What this means for working engineers in mid-July 2025

Three practical positions:

1. If you”re shipping a new SaaS in mid-2025, default to Supabase or Neon. Both have generous free tiers, good DX, and let you ship without thinking about infrastructure. Supabase if you want the all-in-one; Neon if you want pure Postgres.

2. If you have MySQL legacy or high-scale OLTP, evaluate PlanetScale. The Vitess heritage is real for specific workloads.

3. If you”re cost-sensitive and have engineering capacity, self-host Postgres on a Hetzner VPS via Coolify or similar. The math works for many small-team applications.

The honest critique

What this comparison doesn”t cover:

• All three have had outages. Single-point-of-failure on any one provider is a real risk for production apps. Multi-region or multi-provider patterns matter at scale.
• Pricing models change. The PlanetScale free-tier elimination is the cautionary tale. Any of these could reprice in ways that affect your math.
• Migration cost is real. Switching providers later is non-trivial. Pick with intent.
• Cloudflare D1 + Workers is a fourth credible option for read-heavy edge-distributed apps. Not direct Postgres-competitor but adjacent enough to mention.

For most working engineers reading this in mid-July 2025: the three-way Neon vs Supabase vs PlanetScale decision is now mostly about workflow fit and ecosystem alignment. Pick the one that matches your other stack decisions; invest more time in Postgres expertise than platform shopping; have a backup plan for “what if my provider has a bad week.”

For broader database context, see our Cloudflare D1 read replicas analysis and pgvector vs Vectorize guide.