Supabase vs Firebase: Open Source Wins on Price, Firebase Wins on Mobile SDK

Verdict up front: Supabase wins on price, SQL ergonomics, and avoiding vendor lock-in. Firebase wins on mobile SDK polish, offline-first apps, and push notifications. For a web-heavy SaaS: Supabase. For a mobile-heavy consumer app: Firebase — but plan for migration cost when you outgrow the free tier.

The pricing reality at three scales

Side project (1k MAU, 500MB data, 5GB bandwidth/month):

• Supabase Free: €0
• Firebase Spark: €0

Early startup (10k MAU, 5GB data, 50GB bandwidth):

• Supabase Pro: €25/month flat
• Firebase Blaze: ~€40/month (5GB Firestore = €0.90, 50GB bandwidth = €5.40, 10k MAU auth = €0.05, document reads at 1M/day = €31)

Growth stage (100k MAU, 50GB data, 500GB bandwidth):

• Supabase Team: €599/month flat (250GB database, 1M MAU)
• Firebase Blaze: ~€400-1,200/month depending on read patterns (Firestore reads are €0.06 per 100k — easy to hit €500+/month if you have chatty clients)

The Firebase pricing surprise: document reads. A poorly-designed Firestore listener subscribed to a 1,000-document collection costs about €1.80/day per active user. At 10k MAU with 10% active daily, that's €5,400/month just in reads. We've seen this exact bill.

Row-level security: the killer Supabase feature

Supabase exposes Postgres row-level security (RLS) policies as the auth model. You write SQL policies like auth.uid() = user_id and the database enforces them. The client SDK never touches a backend — it talks Postgres directly, with RLS as the firewall.

Firestore has security rules, which are similar in concept but use a custom DSL. Rules are checked per document read/write. They work fine but are harder to test (no SQL EXPLAIN equivalent) and harder to compose across multiple collections (no JOINs in rules).

For a typical SaaS with org-based isolation (user belongs to org, can only see org's data), Supabase RLS is one policy:

CREATE POLICY "org_isolation" ON projects
FOR ALL TO authenticated
USING (org_id = (auth.jwt() ->> 'org_id')::uuid);

Firestore equivalent requires either denormalising org_id into every document or running a Cloud Function for every query.

Offline sync

Firestore wins. Out of the box, the iOS and Android SDKs cache reads locally, queue writes for replay, and resolve conflicts via last-write-wins. For mobile apps where users go on planes, subways, or rural areas — this is critical and hard to replicate.

Supabase has some offline support via PostgREST's caching and the supabase-js client, but you have to wire it yourself. There is no equivalent to Firestore's automatic offline mode. We've shipped a Supabase iOS app that runs offline-first, but it took 3 weeks of caching work that Firestore would have given us free.

Auth providers

Both support email/password, magic link, OAuth (Google, GitHub, Apple, Facebook, Twitter), phone OTP, anonymous. Firebase supports more out-of-the-box: Microsoft, Yahoo, Game Center, Play Games. Supabase supports more open standards: SAML SSO (Pro tier), generic OAuth, LDAP via custom integrations.

For B2C apps: Firebase has more provider polish. For B2B with SSO: Supabase Pro at €25/month with SAML beats Firebase Auth's pricing (Identity Platform with SAML is €0.06/MAU above 50 users — expensive at scale).

Realtime

Both support real-time subscriptions. Supabase Realtime uses Postgres logical replication, broadcasts INSERT/UPDATE/DELETE events. Limits: 200 concurrent connections on free tier, 500 on Pro. Firestore listeners scale to 1M+ concurrent connections.

If you need 10k+ concurrent live listeners (a chat app, live auction, sports scores), Firestore is built for it. Supabase Realtime can do thousands but past that you're better off self-hosting Realtime or using a dedicated pubsub.

Side-by-side

When to choose Supabase

• You know SQL or want to learn it (Postgres is the lingua franca)
• Avoiding vendor lock-in matters
• You want predictable flat pricing
• Web-first product (SaaS dashboard, internal tools, Next.js app)
• RLS-based multi-tenancy is your security model
• You might self-host one day

When to choose Firebase

• Mobile-first product where offline sync matters
• Push notifications are core to the app
• You need to scale to 1M+ concurrent listeners
• Team is mobile-engineer-heavy (more iOS/Android SDK experience than backend)
• You're already in the Google ecosystem (BigQuery, Vertex AI)

Migration: Firebase → Supabase

Typical migration for a 50k-user app with 5 Firestore collections takes 3-6 weeks. Steps:

1. Map Firestore collections to Postgres tables (denormalise carefully — Firestore is doc-based, Postgres is relational)
2. Export Firestore via the GCS export tool
3. Convert NoSQL docs to SQL rows (Python or Node script)
4. Migrate auth (Firebase Auth users export → Supabase import via admin API)
5. Rewrite Cloud Functions → Edge Functions (Deno) or keep them on GCP and just point at the new DB
6. Rewrite security rules → RLS policies (the hardest part — different mental model)

The riskiest piece: rebuilding offline sync if your mobile app depended on it. Plan for a feature freeze on offline edge cases during migration.