Stack8 min read·

Supabase vs Firebase: real bills after 12 months of client work

Honest comparison of Supabase vs Firebase based on 12 months of running both for real client projects. Real costs, real DX, real bugs.

I've shipped 14 projects on Supabase and 6 on Firebase in the last 12 months. Here are the actual bills, the actual bugs, and what I'd pick for which type of project.

TL;DR

  • Supabase for: anything Postgres-friendly, anything with complex relational data, anything where you'll outgrow the platform
  • Firebase for: real-time chat, very simple CRUD, mobile-first apps where you don't need SQL
  • Skip both for: anything with significant compute (use Render/Fly), anything with very simple needs (use SQLite + Litestream)

If you only read one section, read the bugs I hit — that's where the real differences live.

The 12-month bill

Across all client projects on Supabase: $340/month total at peak (5 concurrent active projects).

Across Firebase projects: $220/month total at peak (3 concurrent active projects).

Per-project cost is similar at small scale. The deltas show up in two places: Postgres flexibility and pricing predictability.

Where Supabase wins

1. It's just Postgres

You can run any SQL. You can use any tool that talks to Postgres. You can switch hosts in an afternoon. Firebase's NoSQL model locks you in — there's no migration path that doesn't involve rewriting half your data layer.

2. Pricing is predictable

Supabase's pro plan is $25/month flat plus usage. I can predict next month's bill within $5. Firebase has 10+ different metered dimensions (reads, writes, deletes, function invocations, function compute, storage, bandwidth, hosting requests…) and surprise bills are common.

3. Auth is genuinely good

Magic links, OAuth, MFA, Row Level Security — all in. I haven't needed Auth0 or Clerk on a single Supabase project.

4. The dashboard doesn't make me want to die

Firebase's console is a UX disaster after 5+ years of "improvements." Supabase's dashboard is fast, sensible, keyboard-friendly.

Where Firebase wins

1. Real-time is genuinely magical

Firestore's live listeners "just work" at scale. Supabase Realtime works but has more moving parts and rougher edge cases.

2. Mobile SDKs are mature

React Native + Firestore is a battle-tested combo. Supabase's mobile story has gotten dramatically better in the last year, but Firebase still has a slight edge for mobile-first apps.

3. Cloud Functions are integrated

Firebase Cloud Functions are tightly coupled to triggers (on document write, etc.). Supabase Edge Functions exist but are less integrated.

The bugs I hit

Supabase:

  • Realtime occasionally drops messages under high concurrency (rare, but happened on one client app)
  • The local dev environment can drift from production (use migrations religiously)
  • pgvector queries can be slow without proper indexing — easy to footgun

Firebase:

  • Surprise billing on a misconfigured onSnapshot listener that re-fetched on every change — added $400 to one month's bill before I caught it
  • Cold starts on Cloud Functions can hit 3+ seconds
  • Security rules language is its own DSL with awful error messages

What I pick now

For most client projects in 2026, I default to Supabase unless one of these is true:

  1. The product is real-time-heavy (chat, multiplayer, live cursors)
  2. The client team already uses Firebase
  3. It's mobile-only React Native and the data shape is genuinely simple

Firebase isn't bad — it's just a different tool. Pick based on the product, not on the hype.

If you're picking a stack from scratch, also worth reading: the solo developer playbook and Replit + Claude is the quietly best stack of 2026.


Building something and trying to pick a stack? Start a brief and I'll write back within 24h with a real recommendation. More stack deep-dives in the stack category.


Like this post?

Get the next one in your inbox. No spam, no "hustle culture" emails — just the next post when it's ready.

✦ Keep reading

Got an idea you want to build?

Hire me