The 30-second version
Supabase is Postgres, RLS, PostgREST, GoTrue, and Deno Edge Functions bundled into a managed platform with an open-source runtime. Firebase is Firestore (a proprietary document database), Firebase Auth, Cloud Storage, and Cloud Functions bundled into a managed platform owned by Google. Both let you build a modern app with one SDK, no servers, and a generous free tier. They diverge on data model, authorization mental model, pricing shape, cold-start behavior, and how painful it is to leave. This guide walks each axis honestly so you can pick with your eyes open, not by vibe.
Database model: relational vs document
Supabase gives you Postgres. Full SQL, joins, foreign keys, transactions, and extensions like pgvector for embeddings, PostGIS for geo, and pg_cron for scheduling. Anything a Postgres app has done in the last 30 years works here. Firebase gives you Firestore, a document-collection database where each document is a JSON blob and queries are limited to a single collection with a small set of composite indexes. Firestore is faster to prototype with because there is no schema to define, but as soon as your queries need joins you end up denormalizing aggressively or fanning out reads on the client. Real apps with more than a handful of entities usually feel this pain within the first quarter.
Authorization: RLS vs Security Rules
Supabase uses Postgres Row Level Security. Policies live next to the schema in SQL, apply uniformly to every client and every server that hits the Data API, and are version-controlled with the rest of your migrations. Firebase uses Security Rules, a bespoke DSL evaluated by Google's edge on every read and write. Rules are expressive and low-latency but only cover Firestore and Cloud Storage; Cloud Functions run under their own IAM and are your responsibility to lock down. RLS keeps everything in one language (SQL) and one place (the database). Rules keep everything close to the client but split enforcement across two systems.
Pricing shape: flat compute vs per-operation
Supabase bills for compute (project size), storage (GB), bandwidth (egress), and Auth (monthly active users). A Pro project is $25/month flat with generous included quotas and hard, alertable overages. Firebase bills per Firestore read, write, and delete, plus Cloud Functions invocations, plus egress. At low volume Firebase is cheaper because you pay only for what you use. At scale, per-operation pricing gets expensive and unpredictable: a chatty client that re-reads a collection on every mount can 10x your bill overnight. Supabase's flat compute pricing rewards you for optimizing queries once instead of paying for every roundtrip forever.
Realtime and subscriptions
Firestore's realtime story is excellent and was arguably its original selling point: any query can become a live listener with one method call. Supabase Realtime streams Postgres logical replication events over a WebSocket, with presence and broadcast channels layered on top. The Supabase model gives you more control (you subscribe to specific tables, filters, or channels) but Firestore's model is easier for a beginner to reach for. If your app is a collaborative document editor where every widget listens to a query, Firestore's ergonomics still win. If your app is a dashboard streaming domain events, Supabase's channel model composes better.
Cold starts and serverless compute
Firebase Cloud Functions run on Google's managed container platform. Cold starts range from hundreds of milliseconds to several seconds depending on the runtime and package size, and Node bundles with heavy dependencies feel it most. You can pay for min-instances to keep containers warm, which erases the cold start but also erases the serverless savings. Supabase Edge Functions run Deno on the edge, one isolate per request. Cold starts land in the tens of milliseconds because there is no VM boot and no npm resolution at runtime. For user-facing API traffic the difference is felt on P99, not on averages.
Vendor lock-in and exit ramps
Every piece of Supabase's runtime is open-source: Postgres, PostgREST, GoTrue, Storage-API, Realtime, and the CLI. You can self-host the whole stack with Docker Compose or Kubernetes; the same schema and the same client SDK work end to end. If you outgrow the managed platform, migration is a database dump and a config change. Firebase is fully proprietary. Migrating off Firestore is not a database dump, it is a rewrite: different query semantics, different auth format, different SDK. If long-term optionality matters to you or your customers, Supabase's exit ramp is a real feature.
SDK ecosystem and mobile
Firebase's mobile SDKs are older, more polished, and integrate cleanly with the rest of Google's mobile stack: FCM for push, Analytics, Crashlytics, Remote Config, and App Check. If you are shipping a native iOS or Android app first and web second, Firebase's mobile ergonomics are hard to beat. Supabase's mobile SDKs (Swift, Kotlin, Flutter) are solid and improving, and the Postgres model translates cleanly across platforms, but the surrounding ecosystem (push, crash reporting, feature flags) you assemble yourself from best-of-breed providers.
Who should pick which
Pick Supabase when the data is relational, the team knows SQL, you want the option to self-host, and predictable pricing matters more than absolute lowest cost at tiny scale. Pick Firebase when you are mobile-first, want Google's SDK ecosystem out of the box, are comfortable with document semantics, and would rather pay per operation than per project. Either platform will happily carry a serious production app to millions of users; the choice is mostly about which tradeoffs you would rather live with for the next three years.
Storage and file handling
Supabase Storage is S3-compatible object storage with RLS applied per object via the storage.objects table, and a Smart CDN in front of public buckets. You get presigned upload URLs, image transformations at the edge (resize, quality, format), and buckets that either enforce anon access or route every read through a policy. Firebase Cloud Storage is Google Cloud Storage under the hood, with Security Rules layered on top for authorization. Both are competent; the differences are ergonomic. Supabase keeps the mental model uniform (one policy language, one dashboard), Firebase inherits Google Cloud's broader storage feature set (multi-region buckets, lifecycle rules) at the cost of splitting your auth story across two systems.
Migrations and schema management
Supabase treats the database as the source of truth: you write SQL migrations, check them into git, and run them through the CLI or the dashboard. Because Postgres has schema, the migration tools (from plain SQL files to Sqitch, Drizzle Kit, Prisma Migrate) work exactly as they would against any Postgres. Firestore has no schema, which means migrations become data backfills: read every document in a collection, transform it, write it back, coordinate with client code that must handle both old and new shapes during the rollout. For teams shipping frequent changes, schema-first migrations are dramatically less operational load than schema-less backfills.
Observability and analytics
Both platforms give you invocation logs, error dashboards, and usage counters. Supabase adds a full Postgres logs view, EXPLAIN in the SQL editor, and log drains to Datadog, Logtail, or S3 on paid tiers. Firebase pairs with Google Cloud Logging and BigQuery, so if you already live in the Google stack the observability story is deep. Neither replaces application-level tracing; both work fine with Sentry, PostHog, or OpenTelemetry sidecars. Pick based on where the rest of your logs already go, not on the platform's built-in dashboards alone.