Back to Blog
Cloud

Why I keep choosing Supabase over Firebase, Planetscale, and Neon in 2026

Three years deep on Supabase. The Postgres-native model, the free tier, and the auth integration are why I default to it for new projects. Here are the numbers and the trade-offs.

12 February 202612 min read

Three years using Supabase across SarmaLink-AI, Memo Fashions, the receipt-scanner project, and this site. I have tried the alternatives. Here is why I keep coming back.

Latency

Free tier query latency (ms p50, London)

Source: My own bench, simple SELECT, 30 day average

Free-tier query latency from London. Neon is the fastest, Supabase a close second, Planetscale third, Firebase a distant fourth. For most apps the absolute latency is fine; what matters is whether it is consistent. Supabase's p99 is roughly 4x its p50 (so ~70ms tail). Neon is similar. Firebase has a much wider distribution.

Why Postgres

The single biggest reason. Postgres is the lingua franca. Every ORM supports it, every monitoring tool understands its query plans, every SQL developer can write for it without retraining. When you are deep in a query and need a window function or a CTE, you have it. When you need vector search you install pgvector[2]. When you need full-text search you have tsvector. The ecosystem is wide and old.

Firestore is fine for a CRUD app with no joins. The moment you need a join, an aggregation, a transaction across collections, or a window function, you are in trouble.

Why Supabase specifically

Backend platform comparison, May 2026
SpecSupabaseFirebasePlanetscaleNeon
DatabasePostgresFirestore (NoSQL)MySQL/VitessPostgres
Free tier500MB + 5GB egress1GB Firestore5GB + 1B reads500MB + 1 branch
Auth includedYes (full)Yes (full)NoNo
RealtimeYesYesNoNo
StorageYes (S3 wrapper)Yes (Cloud Storage)NoNo
Edge functionsYes (Deno)Yes (Cloud Run)NoNo
BranchingYesNoYesYes (best in class)
Self-hostYes (full)NoNoNo
Vector searchpgvectorNo (third-party)Nopgvector
Pricing transparencyGoodTrap-y at scaleGoodGood

The differentiator over Neon is the bundled auth, storage, realtime, and edge functions. Neon is the better pure-Postgres host (better branching, better cold start), but you have to BYO auth, storage, realtime, and serverless. For a solo project that work adds up.

The differentiator over Firebase is Postgres versus Firestore. There is no contest if you intend to ship anything analytic or relational.

Pricing reality

Pro tier at $25/month gets you 8GB DB and 100GB egress[1]. That is genuinely enough for most early-stage products. The pricing trap is when you hit egress limits with image-heavy apps; storage bandwidth is metered. I solved this on the receipt-scanner by serving images from Cloudflare R2 instead.

What is not great

Cold start on free tier projects after 7 days of inactivity adds 2-4 seconds the first request. You can pay $25/month to disable this, or you can ignore it for hobby projects.

The dashboard is sometimes slow. Schema changes through the UI are reliable but you should run migrations from code anyway.

The pg_cron jobs are powerful but the UI for them is poor. I use a small TypeScript script to manage them now.

When I do not pick Supabase

  • If I need MySQL specifically (legacy app), Planetscale.
  • If I need the absolute best Postgres branching dev-loop, Neon.
  • If I need a true edge-replicated KV with zero ms reads, Cloudflare KV.
  • If I need a graph database, Neo4j Aura.

For everything else: Supabase. Three years in, no regrets.

About the data

A note on what the numbers in this post represent so you can read them with the right confidence:

  • "My own bench" rows are personal measurements on my own hardware. They are honest about my setup and reproducible there, but they should not be treated as universal benchmark scores.
  • Benchmark numbers attributed to public sources (Geekbench Browser, DXOMARK, NotebookCheck, FIA timing) are illustrative — the trend is what matters, not the third decimal place. Cross-check against the source for anything you would act on financially.
  • Client outcomes and ROI percentages in business-focused posts are anonymised composites drawn from my own consulting work. Real numbers, real direction, sanitised so individual clients are not identifiable.
  • Foldable crease-depth and similar engineering measurements are estimates pulled from teardown reports and reviewer claims; manufacturers do not publish these directly.
  • Forecasts and "what I bet" lines are exactly that — opinions, not predictions with a track record yet.

If you spot a number that contradicts a source you trust, tell me — I would rather correct it than be the chart that was off by 6 percent and pretended otherwise.

References

  1. [1]
  2. [2]
S

Sarma

SarmaLinux

More from Cloud

Have a project in mind?

Let's discuss how I can help you implement these ideas.

Get in Touch