Supabase vs Firebase: Vendor Lock-in Math for Founders

The Supabase vs Firebase decision usually gets framed as a religious argument. Postgres people yell about SQL, Firebase people point at Realtime Database throughput graphs, and someone on Hacker News writes a 4,000-word essay about why one of them is the future and the other is a trap. None of that helps a founder who has to pick a backend on Thursday, ship a v1 in six weeks, and not regret the choice at Series A.

The honest version of this question has three parts. What does each platform actually cost at the volume bands a real SaaS moves through: 1,000 MAU, 50,000 MAU, and 500,000 MAU? What does vendor lock-in cost if you have to leave, measured in engineering weeks and rewrite risk? And which one is the right pick given a specific company stage, team composition, and product shape?

This post is the honest math on all three. It covers real pricing at three volume bands, the structural properties of each BaaS that make migration cheap or expensive, what a real Firebase-to-Postgres or Supabase-to-something-else migration takes in weeks, and where each platform is genuinely the correct answer for a specific kind of founder.

What Supabase and Firebase actually are, structurally

Supabase and Firebase both sell themselves as backend-as-a-service, but they are architecturally different products, and understanding the difference is what makes the vendor lock-in math legible.

Firebase is a proprietary Google product built on Google Cloud primitives. The core services (Firestore, Realtime Database, Cloud Functions for Firebase, Firebase Auth, Cloud Storage, Firebase Hosting, App Check) are Google-specific implementations with Google-specific APIs. Firestore is a document database that does not have a portable equivalent. The client SDKs are the primary interface: your app talks to Firebase directly from the browser or mobile client, and security rules enforced by Firestore are the primary access control layer. There is no "your database" you can dump and reload elsewhere.

Supabase is a hosted layer on top of open source. The core is Postgres. Authentication is GoTrue (open source). Realtime is a Postgres logical replication reader (open source). Storage is an S3-compatible object store with a Postgres metadata layer (open source). Edge Functions are Deno on Deno Deploy. Row Level Security is standard Postgres RLS. Every piece is either open source software you could self-host or a standard interface (Postgres, S3) that portably interoperates with the rest of the industry.

This is not a "Supabase is better" argument. It is a structural fact that changes the shape of the lock-in question. Leaving Firebase means rewriting against a different database model, a different auth system, a different function runtime, and a different security rule language. Leaving Supabase means running the same open source stack somewhere else, or dumping a standard Postgres database and pointing your app at any other Postgres provider. These are two different sizes of migration project, and both have real trade-offs against them.

The trade-off Supabase pays for that portability is maturity. Firebase has been in production at Google-scale since 2014, and every edge case has been mapped by a decade of angry Stack Overflow posts. Supabase hit v1 in 2021 and is still catching up on operational polish for services like point-in-time recovery, cross-region replication, and edge case behavior under load. The gap has narrowed a lot, but it exists.

Real cost math at three MAU bands

Both platforms have a free tier that covers early prototyping, and both have a Pro tier that a real product lives on once it has traction. The comparison gets interesting past the Pro tier, where usage-based billing takes over and the platforms diverge sharply on what they charge for.

1,000 MAU, early stage. A pre-launch or just-launched SaaS with 1,000 MAU, moderate database reads and writes, and no video-heavy storage lands in the free tier or the entry Pro tier on both platforms. Firebase Blaze plan on a modest usage profile typically bills $0 to $30 a month, and most of that is Cloud Functions cold-start and Firestore reads if the app is chatty. Supabase Pro is a flat $25 a month with generous included limits (8 GB database, 250 GB bandwidth, 100 GB storage, 100k monthly active users on Auth), and most 1,000-MAU apps stay entirely inside those limits. The cost difference at this stage is negligible and should not drive the decision.

50,000 MAU, real product-market fit. A SaaS at 50,000 MAU with moderate database activity, a few background jobs, some file uploads, and a decent amount of realtime activity starts to expose the pricing model differences. Firebase at this profile typically runs $400 to $1,800 a month depending on how chatty the app is with Firestore, how much Cloud Functions compute it uses, and how much bandwidth the client SDK is pulling. The variability is high because Firestore charges per document read, per document write, per document delete, and per GB of data transfer, and a poorly-modeled Firestore schema can 10x the bill overnight.

Supabase at the same profile typically runs $150 to $800 a month. The Pro plan is $25 flat, with compute add-ons ranging from an included micro instance up to $110 a month for a small instance, $210 for a medium, $410 for a large, and higher for XL and above. Bandwidth beyond the included allowance runs $0.09 per GB. Storage beyond included runs $0.021 per GB. The pricing shape is closer to standard cloud infrastructure: you pay for compute and data transfer, not for individual API calls. This makes the bill more predictable but also means the compute size has to be tuned to real workload, not left on the default.

The 50,000 MAU band is where a lot of teams start running the numbers. Firebase bills that come in at $1,200 a month are common for chatty B2C apps, and the same workload on a Supabase medium compute instance often lands under $400 a month all-in. That is $10,000 a year of gross margin that becomes available for hiring or runway.

500,000 MAU, scale-stage SaaS. A serious SaaS at 500,000 MAU with heavy database activity, meaningful storage, video or media assets, and production-grade realtime features is a different conversation. Firebase at this profile typically runs $4,000 to $18,000 a month depending on the workload shape. A read-heavy app with a well-modeled Firestore schema and aggressive client-side caching can stay near the low end. A write-heavy or chatty app with unoptimized queries can absolutely spend $50,000 a month on Firestore alone.

Supabase at 500,000 MAU typically runs $1,500 to $6,000 a month. This assumes an XL or 2XL compute instance ($410 to $770 a month), read replicas as needed ($110 to $410 each), 500 GB to 2 TB of bandwidth ($45 to $180), and storage in the several-hundred-GB range ($10 to $50). The bill scales roughly with your infrastructure footprint, which is what founders coming from AWS or GCP are used to.

These are not one-to-one comparisons because the two platforms bundle different things. Firebase includes the client SDK, security rules, and offline sync as first-class features that you would rebuild yourself on Supabase. Supabase gives you a Postgres database that can serve analytics queries, complex joins, and full-text search that Firestore cannot do without a separate system. The dollar difference is real, but the feature difference is real too.

Vendor lock-in: what it actually costs to leave

Lock-in is not a philosophical position. It is a number of engineering weeks it would take to migrate off, plus the risk that some feature you built cannot be reproduced elsewhere without a rewrite. Both platforms have lock-in, and both have costs to leave, but the shapes are different.

Leaving Firebase. A production Firebase app leaning on Firestore, Firebase Auth, Cloud Functions, and Firebase Storage is a nontrivial migration. The database schema is a document model with denormalized relationships, and translating it to Postgres or MongoDB requires re-modeling every collection, rewriting every query, and rebuilding the security rules against a different access control system. Firebase Auth users can be exported with password hashes and imported into other systems, which is one of the cleaner parts of the migration. Cloud Functions are Node.js or Python and port to any serverless runtime with moderate rewriting. Firebase Storage files can be copied to S3 or GCS with a bulk transfer job.

The client SDK is the sticky part. A React or Flutter app that uses the Firebase SDK for realtime data, auth, offline sync, and file uploads has that SDK woven into every screen. Ripping it out and replacing it with a different backend means touching every component that reads or writes data. For a moderate-complexity app, this is 8 to 20 engineering weeks of work, and the migration risk is high because you are replacing tested integrations with new ones under production traffic.

Real Firebase migration budgets for a 50,000 MAU app typically land at $80,000 to $220,000 depending on complexity, with a calendar time of three to six months and a required parallel-run period where both systems process live data before cutover. Some teams do this successfully. Many find that once they run the numbers, staying and optimizing Firestore usage is cheaper than migrating.

Leaving Supabase. A production Supabase app is running Postgres. Leaving Supabase for AWS RDS, Neon, Crunchy Bridge, Fly.io Postgres, or a self-hosted Postgres cluster is a database dump and restore, plus a connection string change in your app. The schema and data port unchanged. Row Level Security policies are standard Postgres and travel with the database. Auth users are stored in a Postgres schema and can be exported into most other auth systems, though there is some rework because the token format and password hash structure is specific to GoTrue.

Storage is S3-compatible and the metadata is in Postgres tables you already have. Realtime is a Postgres logical replication reader, and if you leave Supabase, you either stand up your own replication reader or switch to a different pattern (LISTEN/NOTIFY, third-party CDC tooling like Debezium, or a hosted alternative like PowerSync). Edge Functions on Deno Deploy are less portable and probably need rewriting for your target runtime, but they are typically thin business logic on top of the database rather than a large surface area.

A realistic Supabase-to-somewhere-else migration for a 50,000 MAU app runs 2 to 6 engineering weeks and $15,000 to $50,000, and the risk profile is much lower because the database itself is unchanged. Some teams do this move preemptively at Series A because their VC or CTO wants the infrastructure on their own AWS account rather than on a third-party BaaS. It is a meaningful project but it is not a rewrite.

The lock-in delta between the two platforms is the real vendor lock-in argument, and it is honest to say the delta is large. Firebase migration is a rewrite project. Supabase migration is a database move. If you think you might leave, that gap matters.

Where Firebase is genuinely the right pick

Firebase gets a lot of unfair flak in the Supabase-friendly parts of the internet, and it is worth being direct about where Firebase is the correct call and stopping there.

Mobile-first consumer apps with heavy offline sync requirements. The Firebase SDK's offline persistence for Firestore is genuinely excellent and has been battle-tested for a decade in flaky-network conditions. If your app needs to work on a subway, in rural areas, or in emerging markets with intermittent connectivity, Firebase's offline sync is a durable feature that Supabase's Realtime does not match yet. Rebuilding this yourself against Postgres is a large project.

Teams already deep in the Google Cloud ecosystem. If your infrastructure is on GCP, your identity is on Google Workspace, your analytics is BigQuery, and your team knows the Google console, adding Firebase is friction-free. The integration between Firebase and the rest of GCP (Cloud Run, Pub/Sub, BigQuery export from Firestore, Google Analytics 4 tie-in) is real and useful.

Rapid B2C prototyping where the client SDK matters more than the backend. The Firebase JavaScript, iOS, and Android SDKs let a small team ship a working app with auth, database, and realtime updates in a weekend. The Supabase JS client is good, but the ecosystem of tutorials, sample apps, and Stack Overflow answers is deeper on the Firebase side, and for a solo founder or two-person team building a consumer app in a hackathon-adjacent timeline, that gap matters.

Apps with heavy push notification requirements. Firebase Cloud Messaging is the standard for cross-platform push and integrates cleanly with the rest of Firebase. Supabase does not offer a native push service, so a Supabase-based app usually integrates OneSignal, Expo Push, or a rolled-in-house solution.

Apps where document modeling actually fits the data. Some data is genuinely document-shaped: user-generated content with variable fields, nested comment threads, activity feeds with heterogeneous events. Modeling this in Postgres works, but Firestore's document model is honestly a better fit for some categories of app, and forcing it into a relational schema for portability reasons is a decision worth being deliberate about.

If two or more of these describe your situation, Firebase is the right pick and the lock-in cost is worth paying because the alternative is more expensive.

Where Supabase is genuinely the right pick

Supabase is the correct answer more often than Firebase for a specific kind of company, and the profile is worth naming directly.

B2B SaaS with relational data. Users, organizations, projects, subscriptions, invoices, audit logs, and reporting queries are all relational shapes that Postgres handles natively. Building the same schema in Firestore requires either denormalization (with all the write-fanout costs) or creative document design that inevitably breaks under a real product manager asking for a filtered report by tenant, status, and date range. If your product is any B2B tool that will end up with tenants, roles, and permissions, Supabase is the shorter path.

Products with meaningful analytics or reporting needs in-product. A Postgres database can serve product analytics, cohort queries, admin dashboards, and customer-facing reports directly. Firestore cannot: you have to export to BigQuery and build a separate analytics stack. For any product where the founder ends up wanting a real admin panel or the CS team needs to run ad-hoc queries, Supabase saves you from building a second system.

Teams that already know SQL and Postgres. If your engineers are comfortable with SQL, migrations, RLS, and standard relational modeling, Supabase gives them the tools they already know. Firebase is a new mental model that requires learning document design, security rules language, and Firestore's query semantics, which is a real ramp-up cost for a team that has none of those skills.

Founders who care about vendor lock-in as a strategic consideration. The Postgres portability story is the entire argument. If you might raise money and get pushed to move infrastructure onto AWS or GCP-direct, if you might get acquired and have to fit into a different infra stack, or if you just do not want to be one repricing announcement away from a rewrite, Supabase's open source foundation and standard Postgres core is a real hedge.

Products with realtime collaboration requirements. Supabase's Realtime, built on Postgres logical replication, works well for collaborative documents, live cursors, presence, and pub/sub-style channels. Firebase's Realtime Database also does this well, but for teams that want the same data model to power the CRUD API and the realtime feed, Supabase's approach is architecturally cleaner.

If three or more of these describe your product, Supabase is the shorter and cheaper path from now through Series A, and the vendor lock-in argument is a durable strategic benefit rather than a talking point.

The BaaS comparison that actually matters: cost vs speed vs optionality

Every BaaS comparison eventually comes down to three axes, and the honest way to pick is to know which axis matters most for your specific situation.

Cost. At 1k MAU, the two platforms cost the same. At 50k MAU, Supabase is typically 30 to 60 percent cheaper for the same workload. At 500k MAU, Supabase is typically 50 to 70 percent cheaper. The gap is real and it compounds with growth. For a bootstrapped SaaS or a founder trying to extend runway, the multi-year cost difference between the two platforms can pay for a hire.

Speed to v1. For a mobile consumer app, Firebase's SDK ecosystem is faster to ship the first version. For a B2B web app, Supabase is faster because the schema, auth, and RLS map to how a B2B product actually works. Neither is universally faster; the answer depends on product shape.

Optionality. Supabase's Postgres foundation gives you the option to leave without rewriting. Firebase's proprietary services give you a mature, integrated, high-quality product with a heavier exit cost. Optionality is worth something and it is not worth infinite money, and different founders will weight it differently.

The founders who pick Firebase and are right about it usually value speed and integration over optionality, and they are shipping a consumer product where the SDK story is doing real work. The founders who pick Supabase and are right about it usually value cost, relational data modeling, and long-term optionality, and they are shipping a B2B product where the Postgres foundation matches how the product will need to grow.

The founders who pick either one and are wrong about it usually picked based on Twitter opinions rather than product shape.

What migration off actually looks like, honestly

If you are already on one and considering the other, the migration project is worth scoping before deciding.

Firebase to Supabase. This is the more common direction and the more expensive migration. A moderate-complexity app takes 8 to 16 engineering weeks. The phases are usually schema design (translating Firestore collections to Postgres tables with proper relations), data migration (bulk export from Firestore, transform, bulk import into Postgres), auth migration (exporting Firebase Auth users with hashes and importing them into Supabase Auth using the compatible bcrypt format), function rewrite (Cloud Functions to Edge Functions or a separate compute layer), and client rewrite (Firebase SDK calls replaced with Supabase client calls or a REST layer).

The client rewrite is usually the largest single line item. For a Flutter or React Native app that used Firebase everywhere, every screen touches. Teams that scope this well use the migration to also introduce a proper API layer (tRPC, GraphQL, or REST) between the client and the database, which pays back long-term even beyond the migration.

Supabase to somewhere-else Postgres. This is a much smaller project. A pg_dump and pg_restore against your target Postgres instance, plus updating connection strings, plus deciding what to do with GoTrue Auth (either self-host it, migrate to a hosted alternative like Clerk or Auth0, or roll your own), plus deciding on a Realtime replacement if you were using it. Two to six engineering weeks for a moderate-complexity app. This is why the vendor lock-in argument for Supabase is honest.

Supabase to Firebase. Uncommon but occasionally requested when a team needs Firebase's offline sync or push notification story. This is essentially a rewrite because you are moving from relational to document, and the schema translation goes the wrong direction (denormalizing usually loses information). Budget it like the reverse Firebase-to-Supabase project or worse, and only do it if the specific Firebase features you need are not achievable any other way.

The founder decision framework

Four questions determine which BaaS is the right pick for a specific SaaS.

First, what shape is your data? If it is relational (users, organizations, projects, invoices, standard SaaS objects with joins and reports), pick Supabase. If it is document-shaped (user-generated content, activity feeds, heterogeneous records), Firebase is a serious contender. If you are not sure, the safe answer is relational, because you can always denormalize into JSONB columns in Postgres, but you cannot easily un-denormalize a Firestore schema later.

Second, what is your growth trajectory and cost sensitivity? A bootstrapped SaaS aiming for 500k MAU on tight margins should model out the three-year cost curve on both platforms with realistic usage assumptions before picking. A VC-backed consumer app with 18 months of runway to product-market fit and cost as a tertiary concern can prioritize other factors.

Third, what does your team already know? A team with strong Postgres, SQL, and Node experience will ship faster on Supabase. A team already fluent in Firebase who has shipped multiple apps on it will ship faster on Firebase. Fighting your team's existing skills to save 30 percent on infrastructure is often a bad trade at the seed stage.

Fourth, how much does optionality matter to you? If you have a strong belief that infrastructure choices should be reversible, Supabase's Postgres foundation is a real answer to that question. If you value integrated products over portable ones and you are willing to trade optionality for polish, Firebase's decade of maturity is worth the lock-in tax.

There is no universal winner in the Supabase vs Firebase comparison. There is a right answer for a specific founder building a specific product at a specific stage. The founders who agonize over the choice for weeks are usually the ones who should just build a small proof of concept on each and let the ergonomics decide, because both are legitimate BaaS options and both will let you get to a working product faster than assembling the same stack from scratch on raw AWS or GCP.

The founders who get burned are almost never the ones who picked the "wrong" platform. They are the ones who did not model the cost curve for their actual workload, did not consider the exit cost when they were choosing, or picked based on internet consensus rather than what their specific product needed. The choice is not the trap. The trap is choosing without doing the math.