Firebase has been the default BaaS for years. Spin up a project, point your mobile app at it, and you’re live by lunch. That reputation stuck — but so has a growing list of developers who opened an unexpected $800 bill and quietly started Googling alternatives.
Supabase hit $70M ARR in August 2025, growing 250% year-over-year. Their developer count went from 1M to 4.5M in under a year. That’s not hype anymore — that’s a real migration wave. I’ve spent time with both platforms across different projects, and the choice between them is less obvious than the marketing suggests.
Here’s what actually matters when you’re picking one for a real project.
The Fundamental Architecture Difference
This is where the comparison starts and where most people underestimate the impact.
Supabase is PostgreSQL. Not “PostgreSQL-inspired” or “SQL-compatible.” It’s a managed Postgres instance with PostgREST auto-generating REST and GraphQL APIs from your schema, plus Realtime built on top of Postgres’s WAL. Everything you know about relational databases applies. Joins work. Constraints work. Migrations work. You can connect with any Postgres client.
Firebase is a document store. Firestore uses collections and documents — flexible but denormalized. If your data has relationships, you’re either duplicating it or doing client-side joins that would make a DBA cry.
Neither is objectively better. The question is what your data looks like. An e-commerce app with orders, products, customers, and inventory belongs in a relational model — Supabase wins there, clearly. A real-time collaborative document editor or a mobile app that needs offline sync? Firebase’s Firestore has a strong case.
Where I’ve seen developers go wrong is picking Firebase because it feels easier to start with, then spending weeks fighting the data model when requirements add complexity. The JOIN you couldn’t write in Firestore turns into five read operations and client-side merging. It works, but it’s expensive in both cost and code.
Real-Time Capabilities
Both platforms offer real-time features, but they work differently and have different trade-offs.
Supabase Realtime streams database changes via WebSocket, using Postgres’s Write-Ahead Log (WAL) as the source of truth. When a row updates, clients subscribed to that table see the change. The architecture means you’re getting exactly what’s in the database — no eventual consistency questions.
Firestore’s listeners are arguably the better developer experience for simple cases. The client-side SDK handles reconnection, offline caching, and delta updates automatically. On mobile especially, this is genuinely impressive.
The catch with Firestore: you pay for every read. If your real-time subscription triggers on a document that gets updated frequently, those reads stack up. Supabase Realtime doesn’t charge per row change — it’s included in your plan up to certain connection limits.
For apps where real-time is a core feature (chat, live dashboards, collaborative editing), this pricing difference matters more than the developer experience difference.
Auth: Similar Until You Hit Scale
Both platforms cover the basics: email/password, magic links, OAuth with Google/GitHub/Apple, and phone/SMS. In terms of available providers, you’re not going to miss anything on either side.
The structural difference is how they handle authorization after authentication.
Firebase Security Rules are a domain-specific language that lives separately from your data. They’re powerful but have a learning curve, and testing them properly requires either the emulator suite or careful production validation.
Supabase uses Row Level Security (RLS), which is native Postgres. You write SQL policies that filter queries automatically. If you already know SQL, this feels natural. auth.uid() = user_id is the most common policy you’ll write, and it works exactly as you’d expect.
I find RLS more maintainable for complex permission models. The rules live close to the data, they’re testable with standard SQL tools, and they scale with your query complexity without a separate rules language to learn.
Pricing: both platforms offer 50,000 MAUs free. After that, Supabase Pro includes 100,000 MAUs at $25/month base. Firebase Auth is free beyond 50K MAUs for standard sign-in methods, but SMS authentication — critical for phone-based apps — costs between $0.01 and $0.34 per message depending on the destination country. For apps with any significant SMS usage, this adds up fast and it’s not obvious from the free tier experience.
Storage: Basically a Tie at Small Scale, Diverges Later
Supabase Storage uses S3-compatible object storage under the hood. Firebase uses Google Cloud Storage. Both give you reasonable free tiers (1 GB each) and both work well for the basics: file uploads, download URLs, image transformations.
The pricing difference shows up at scale. Supabase Pro includes 100 GB of storage. Firebase Blaze charges $0.26/GB beyond the free 5 GB on the Spark plan. For a media-heavy app storing user uploads, that gap becomes real quickly.
Neither platform’s storage is their strongest feature. If storage is your primary concern, you might be better off with S3 directly. But for most apps where storage is a secondary concern, both options are fine and either integrates without friction.
The Cost Conversation You Need to Have Before Choosing
This is where Firebase’s reputation has taken the most damage in the last two years.
Firebase Blaze is pay-as-you-go with no hard spending caps. You can set budget alerts, but they’re informational — they don’t stop charges. Budget alerts also lag by hours or sometimes days. Several developers have written about opening their Firebase console to find bills 10x what they expected after a traffic spike, a scraper hit their app, or a poorly-optimized query ran in a loop.
Supabase has usage-based overages too, but the base pricing is more predictable. The $25/month Pro plan includes a defined allocation: 8 GB database, 100K MAUs, 100 GB storage, 50 GB egress. Beyond that, you pay for what you use. The difference is you start with a clearer baseline.
Here’s a concrete scenario: a typical SaaS app at early growth stage — 10,000 MAUs, 500 GB monthly reads (moderate usage), 20 GB storage, no SMS auth.
Supabase: $25/month Pro. 10K MAUs is well within the 100K included. Storage well within 100 GB. 500 GB reads don’t map directly to Supabase’s pricing model (which charges on egress and compute, not raw read counts). Realistically $25-40/month.
Firebase Blaze: At $0.18 per 100K Firestore reads, 500M reads (scaled up from a typical app with ~50 reads per DAU) would be $900/month. That math sounds extreme, but poorly structured Firestore queries or any UI that fetches full collections can easily hit these numbers. With a well-optimized app — careful query design, pagination, limited real-time subscriptions — Firebase can be much cheaper than this. But the risk is unpredictable.
The honest answer: Firebase can be cheap if your query patterns are disciplined. The problem is that it requires discipline that Postgres’s query model doesn’t punish you for lacking. With Supabase, a slow query is a performance problem. With Firebase, an inefficient read pattern is both a performance problem and a surprise invoice.
Leaving: One Exit Is Much Cleaner
Vendor lock-in is worth thinking about before you build on any managed platform.
Leaving Supabase: Your data is in Postgres. pg_dump it, point a connection string somewhere else, done. The REST API layer (PostgREST) is open source. Supabase itself is open source — you can self-host the entire stack with Docker. You might rewrite some client-side code if you switch to a different backend, but your data is genuinely portable.
Leaving Firebase: Firestore exports are JSON or CSV dumps of your documents. The structure is Firebase-specific, and any application code using the Firebase client SDKs will need to be rewritten, not just repointed. Security Rules need to be reimplemented in whatever auth/authorization system you move to. It’s doable, but it’s a migration project rather than a data export.
This asymmetry matters more as your app grows. A startup at 10K users can afford a migration. A mature app at 500K users with two years of Firebase-specific client code is meaningfully locked in.
Framework and Ecosystem Compatibility
Supabase has first-class JavaScript/TypeScript clients, Flutter support, and community clients for most other languages. The REST and GraphQL APIs mean you can use it from anything that can make HTTP requests.
Firebase’s SDK ecosystem is broader for mobile — particularly for Android and iOS, where Google’s tooling has years of polish. Offline persistence in Firestore is genuinely good. If you’re building a React Native or Flutter app where users might have spotty connectivity, Firebase’s local caching and sync story is more mature.
For web applications, both are roughly equivalent in terms of integration effort. Supabase’s developer experience has improved significantly — the dashboard is clean, the docs are good, and the local development story with supabase start (Docker-based local stack) is excellent.
Local Development and Testing
This is a practical difference that matters during day-to-day development.
supabase start spins up the entire Supabase stack locally via Docker: Postgres, PostgREST, GoTrue for auth, the Realtime server, and even the Studio UI. Your local and production environments are structurally identical. You can write and test migrations locally, run RLS policies against real data, and push to production with supabase db push. The feedback loop between local development and production is tight.
Firebase has the Firebase Emulator Suite, which is functional and has improved a lot. But the emulators don’t perfectly mirror production — there are known edge cases around Security Rules evaluation and Firestore indexing behavior that only surface in production. It’s good enough for most development, but “good enough” is doing some work in that sentence.
For teams that care about local-first development or who work across different environments (local, staging, production), Supabase’s approach is more coherent. The Docker dependency adds some setup overhead, but the payoff is an environment you can actually trust.
What Happens at Scale
Neither platform is magic above a few million users, but the failure modes differ.
Supabase is Postgres under the hood, which means the same scaling strategies that work for any Postgres deployment work here: read replicas, connection pooling via PgBouncer (included on Pro), indexing. When you outgrow the managed offering, your data is in a standard format you can migrate to RDS, Cloud SQL, or self-hosted Postgres with a tool like pg_dump.
Firebase’s Firestore is designed to scale horizontally without intervention — you genuinely don’t think about database scaling until very high traffic levels. That’s a real advantage for apps with unpredictable growth curves or bursty traffic. The trade-off is that Firestore’s scaling model constrains your data design from the start. “Design for your queries” is Firebase’s core philosophy, which works when your query patterns are known and stable. When they’re not, you pay for the mismatch.
When to Pick Which
Pick Supabase if:
- Your data has relationships — users, orders, products, anything with foreign keys
- You want predictable monthly costs and don’t enjoy surprise bills
- You plan to do anything complex with authorization (multi-tenant apps, team permissions, role hierarchies)
- Long-term flexibility matters — you want an exit that doesn’t require a full rewrite
- You’re already comfortable with SQL
Pick Firebase if:
- You’re building a mobile-first app where offline sync is a real requirement
- Your data model is genuinely document-shaped and you won’t need complex queries
- You’re deep in the Google ecosystem and GCP integration matters
- Your team has existing Firebase expertise and the migration cost isn’t justified
The hybrid option exists: some teams use Firebase Auth (mature, battle-tested) with a different database backend. That’s a legitimate architecture, just more infrastructure to manage.
One Thing Most Comparisons Miss
The hidden cost isn’t the per-unit pricing. It’s the operational cost of managing Firebase’s query patterns.
With Postgres, you write a query and it either returns data efficiently or shows up in your slow query log. The feedback loop is tight. With Firestore, you often don’t know your query patterns are expensive until you see the bill. Restructuring a Firestore data model mid-production — because you realized you need a query pattern you didn’t anticipate — is a painful migration.
Supabase doesn’t eliminate database design problems. But at least it uses a data model and tooling that the industry has spent 40 years optimizing for exactly these problems.
If you’re starting a new project today and don’t have a specific reason to choose Firebase, the weight of evidence points toward Supabase. Check the official Supabase pricing against your expected usage before committing — the Pro plan’s included allocation covers most early-stage apps without surprises.