Supabase vs Firebase Pricing: What You Still Build

The verdict. These are not three databases. They are three different amounts of platform work you agree to own. Pick Supabase when you want Postgres, SQL, and a managed layer for auth, RLS, realtime, storage, functions, backups, and logs. Pick Firebase when a full managed backend and client-first realtime workflow matters more than SQL portability. Pick plain Postgres when your data model or workload needs it and you are willing to assemble auth, storage, realtime, observability, and operations yourself. The question is not “which database is best?” It is: which layer do I want to build, and which meter am I willing to watch?

This is a Workflow Decision Lab piece, not a “three best databases” list. The mistake is choosing on the free-tier logo, then discovering you also needed identities, files, backups, and alerts.

Proof status. Prices below are quoted from the vendors’ own pricing pages as of 21 August 2026 and linked at every figure. The worked example is arithmetic from those published rates, with its assumptions shown. Firebase’s fetched page sends paid Firestore pricing to Google Cloud pricing rather than stating a per-read rate, so that part is explicitly marked unverified, re-check before publishing. Pricing changes; re-run the links before committing a year.

1. The operator

You are an indie builder on your fourth SaaS targeting 50K MAU. You need roles, social login, MFA, uploads, live screens, and reporting that will eventually ask for joins. You do not want to reinvent password reset or get a mysterious read-heavy bill.

2. The mechanism: what you are actually buying

Supabase is managed Postgres plus Auth, Storage, Edge Functions, Realtime, backups, logs and a dashboard (Supabase pricing, as of 21 Aug 2026). Firebase adds Authentication, Firestore, Realtime Database, Functions, Storage and Hosting (Firebase pricing, as of 21 Aug 2026). Plain Postgres is the engine; adjacent product decisions remain yours.

Capability	Supabase: who does it	Firebase: who does it	Plain Postgres: who does it
Auth	Supabase Auth; configure providers, policies, and email/SMS delivery	Firebase Authentication; configure providers and client flows	You choose/integrate an auth service or build it; you own session and identity integration
RLS / security rules	PostgreSQL RLS policies; you write and test the policy	Firebase Security Rules and custom claims; you write and test the rule model	You design authorization in the API/database and test it
Realtime	Supabase Realtime over Postgres changes, Broadcast, or Presence	Firestore/Realtime Database client subscriptions	You build WebSockets/SSE, change propagation, fan-out and backpressure, or buy it
File storage	Supabase Storage and access controls	Cloud Storage for Firebase	Choose object storage, signed URLs, lifecycle rules, CDN and access control
Migrations	SQL migrations/CLI and a Postgres schema	Data-model and rules deployments; no relational SQL migration path for Firestore	You run a migration tool, review rollouts and recover failures
Observability	Dashboard/logs; Pro includes 7-day log retention	Firebase/Google Cloud tools; configure what you need	Pick logs, metrics, tracing and alerting; wire them into the app
Backups	Managed database backups; Pro includes daily backups retained 7 days	Managed service durability, but you define export/recovery approach for your data	Configure backups, retention, restore drills, replicas and upgrade plan

The table is the decision. Firebase gives the most managed surface but asks you to accept its document model and Google Cloud coupling. Supabase preserves SQL while removing much of the glue. Plain Postgres hands you the most glue.

3. The prices that change the conversation

Platform	Free entry line	Paid meters	Caveat
Supabase	$0, 50,000 MAUs, 500 MB DB, 1 GB files, 5 GB egress; inactives pause after 1 wk (pricing, 21 Aug 2026)	Pro $25/mo: 100K MAUs then $0.00325/MAU, 100 GB files then $0.0213/GB, 250 GB egress then $0.09/GB, realtime >5M at $2.50/M	Pro includes a $10 compute credit and unlimited API requests — API reads alone aren’t a meter
Firebase	Spark 50K MAUs; Firestore 50K reads/day, 20K writes/day, 1 GiB stored, 10 GiB/mo egress (pricing, 21 Aug 2026)	Blaze bills usage: RTDB storage $5/GB after 1 GB, downloads $1/GB after ~10 GB/mo, legacy storage $0.026/GB after 5 GB	Paid Firestore rates link out to Google Cloud, not the fetched page; phone auth is per-SMS
Railway Postgres	Free $0 + $1 credit; Hobby $5/mo incl. $5 credit (pricing, 21 Aug 2026)	Volumes $0.00000006/GB-s, memory $0.00000386/GB-s, CPU $0.00000772/vCPU-s, egress $0.05/GB	A hosting baseline — no auth/realtime/storage; those are separate bills

The meters differ. Supabase has unlimited published API requests but charges for storage, egress, compute, realtime and MAUs. Firebase has separate meters for reads, bandwidth, storage, functions and hosting. Railway charges resources by the second; the plain stack also has integration and on-call work.

4. Worked example: 50K MAU, 10M API reads/month, 200GB storage

Assumptions. Labels, not a forecast. One project; 50K MAUs; 10M reads/month; 200GB of files for 30 days; no egress, realtime, functions, extra CPU/memory, or third-party auth. These are known components, not all-in quotes.

Option	Calculation (published rate)	Proven monthly
Supabase Pro	$25 + (200 GB − 100 GB) × $0.0213/GB = $27.13 (pricing, 21 Aug 2026)	$27.13 minimum — excludes egress, compute, Realtime, functions
Firebase + Firestore	Legacy storage (200 GB − 5 GB) × $0.026/GB = $5.07 (pricing, 21 Aug 2026)	$5.07 storage only — Firestore reads/data/egress are unverified (link out to GCP)
Postgres on Railway	200 GB × $0.00000006/GB-s × 2,592,000 s = $31.10 (pricing, 21 Aug 2026)	$31.10 volume only — CPU/RAM, egress, backups are extra or self-built

Firebase’s database-read total cannot be computed from the page we fetched. Supabase’s $27.13 excludes egress, Realtime, bigger compute and auth at scale.

5. Where it fails

• Firebase: lock-in arrives through the application shape, not just the database. Document paths, SDK calls, Security Rules, Cloud Functions and listeners become your contract. Deep SQL joins and arbitrary reporting are a product tax. Firestore and Realtime Database are separate services with separate quotas/meters (Firebase, as of 21 Aug 2026); a migration is not a swap.
• Supabase: “unlimited API requests” does not mean unlimited bill. Read-heavy apps can still emit realtime messages, serve files, generate egress and require bigger compute. Pro’s published overages include $2.50/M realtime messages above 5M, $0.09/GB egress above 250GB, and compute beyond the included Micro credit (Supabase, as of 21 Aug 2026). Turn on spend caps and watch the usage page before you turn them off.
• Plain Postgres: you are the platform team. You still own backups, restore drills, scaling, migrations, pooling, auth, permissions, storage, realtime and alerts. Clerk or Auth0 can be rational; they are also another fee and integration surface. “Postgres is cheaper” is false if it buys you a second job.

6. When NOT to use each one

Do not use Firebase as the default if your core product needs deep SQL joins, relational constraints, ad-hoc analytics, or an unusual workload that does not fit document reads and listeners.

Do not use Supabase if you need an unusual data engine, custom network topology, or full control over extensions, upgrades and operations. Its managed layer is the point, and sometimes the boundary.

Do not start with plain Postgres if the goal is to ship this week and you would rather not assemble auth, uploads, realtime, backups and observability. The alternative is delayed launch and unpaid ops.

7. The 30-day test

Run one thin vertical slice for 30 days: social login, a role-gated screen, an upload, a live update, and a backup/restore exercise. Record five numbers:

1. 50K-MAU headroom: actual MAUs divided by allowance. 50K is all of Supabase Free’s allowance, half of Pro’s 100K, and Firebase Authentication’s no-cost threshold (Supabase, Firebase, as of 21 Aug 2026).
2. 10M-read shape: count document reads/listener events versus SQL/API requests. Flag Firebase days above 50K Firestore reads (Firebase, as of 21 Aug 2026).
3. 200GB-storage delta: compare the actual storage line and download/egress to the assumption.
4. Time to ship: target five working days or less. If plain Postgres still lacks auth, files or authorization tests at day five, it is not your lower total cost.
5. Restore/incident minutes: complete one tested restore and target under 60 minutes of unplanned platform work.

Keep the option that ships the slice, passes the authorization test, and produces an invoice you can explain line by line. That is a better decision rule than MAU mythology.

Bottom line

Supabase, Firebase and plain Postgres are not interchangeable database brands. Supabase buys you Postgres plus a managed platform layer. Firebase buys you the broadest managed backend and asks you to accept its model and ecosystem. Plain Postgres buys you the engine and makes you responsible for the rest.

For the named operator: start with Supabase if SQL, roles, social login and MFA matter and you want to ship without becoming the backend team. Choose Firebase only when its client-first model is a feature, not an accident. Choose plain Postgres when the workload needs its control and you have budgeted services and operator time. The bill jump is often the platform layer you were building all along.

---

More on this decision, three ways to look at it: