Pick a BaaS: Firebase vs Supabase

Five services wrapped in one SDK

Both Firebase and Supabase bundle the same five capabilities behind one SDK and one set of credentials:

• Authentication — email/password, Google / Apple / GitHub OAuth, magic links, phone OTP. The SDK gives you "is the user signed in" as a one-line check.
• Database — where your app's data lives. Firebase = Firestore (NoSQL documents); Supabase = Postgres (relational rows).
• Storage — file uploads. Profile photos, attachments, user-generated images. Both expose a bucket-shaped API; Firebase backs it with Google Cloud Storage, Supabase with S3.
• Realtime — push-based updates to clients on data change. The "live counter that updates everywhere" demo. Firestore has it everywhere by default; Supabase has it on tables you opt in.
• Functions — server-side code triggered on events or HTTP. Firebase Cloud Functions (Node) and Supabase Edge Functions (Deno).

The thing you're paying for, beyond hosting, is that all five are wired to the same user identity. A signed-in user's photo upload (storage) is allowed because of a row-level rule (database) referring to their auth token (authentication). Rolling this yourself means writing that wiring; with a BaaS, the SDK hands you the wired-together version.

Firestore optimizes for one shape; Postgres optimizes for change

The single most important difference between Firebase and Supabase is the database. Pick this badly and every later feature is a fight with the schema.

Firestore (Firebase) — NoSQL documents. Data lives in collections of documents; a document is JSON. There are no joins. There are no foreign keys. There are no migrations — schemas exist only in your code. Queries are simple ("documents in this collection where field X equals Y") and very fast at scale, but anything multi-table-ish (think SQL joins) has to be either denormalized into the document or done client-side by fetching multiple collections. Realtime sync is everywhere by default; this is what Firebase is famous for.

Postgres (Supabase) — relational rows. Data lives in tables with typed columns and a schema you define up front. Joins exist. Foreign keys exist. SQL is the query language; the Supabase SDK wraps a query builder over it, but you can also write raw SQL when you need to. Schema changes are migrations — text files in your repo that move the database from one shape to another. Realtime is opt-in per table.

The rule of thumb that holds up surprisingly well: if your app feels like "a feed of posts with comments and likes," Firestore is fine. If it feels like "users, projects, tasks, assignments, with reports across all of them," you'll fight Firestore and Postgres wins. Most real consumer apps drift toward the second shape over a year of iteration, even if they started looking like the first. That bias is the main reason teams pick Supabase as a default in 2026.

What both SDK tours don't show you

The exit-cost row matters more than people expect. Apps that succeed grow into needs that the original BaaS choice didn't anticipate. With Supabase, "I need to move off" is "pg_dump then run the app against a different Postgres." With Firebase, it's a project measured in months.

Both are free until they aren't; understand the cliff

Both have generous free tiers that cover personal projects and small SaaS. Both jump to a paid plan when you exceed quotas. Both then meter usage on top of the base plan.

Firebase (Spark → Blaze). The Spark plan is free and includes 1 GiB Firestore, 1 GB storage, 10 GB transfer, 50K daily Firestore reads, 20K writes. Past that, you switch to Blaze (pay-as-you-go): $0.06 per 100K Firestore reads, $0.18 per 100K writes, $0.026/GB-month storage. The infamous "Firebase bill" stories are usually a misconfigured client doing infinite reads in a loop on Blaze — the meter doesn't stop. Set a daily budget alert on the GCP project before going to production.

Supabase Free → Pro. Free includes a 500 MB Postgres database, 1 GB storage, 50K monthly active users, 5 GB egress. Pro is a flat $25/month plus usage — 8 GB DB, 100 GB storage, 100K MAU, 250 GB egress. Above Pro is enterprise pricing. The pricing is more "subscription-shaped" than Firebase's pure usage meter; bills don't accidentally explode but plan changes have to be deliberate.

For a real app with ~10K monthly active users and moderate data: both run $25–60/month at the entry paid plans. The curves diverge above that — Firebase scales smoothly with traffic; Supabase has step-changes at plan boundaries (Pro → Team → Enterprise).

Sign in with Google, read one document

One-time setup: Firebase console → Add project. Inside: Build → Authentication → enable Google. Build → Firestore Database → create in test mode. From the project settings, copy the web config object (an apiKey and a handful of IDs).

In your project:

npm i firebase

Create src/firebase.js:

import { initializeApp } from "firebase/app";
import { getAuth, GoogleAuthProvider, signInWithPopup } from "firebase/auth";
import { getFirestore, doc, getDoc } from "firebase/firestore";

const app = initializeApp({
  apiKey: "AIza...",
  authDomain: "your-project.firebaseapp.com",
  projectId: "your-project",
  // ...rest of config
});

export const auth = getAuth(app);
export const db = getFirestore(app);
export const signInWithGoogle = () =>
  signInWithPopup(auth, new GoogleAuthProvider());

export async function getProfile(uid) {
  const snap = await getDoc(doc(db, "profiles", uid));
  return snap.exists() ? snap.data() : null;
}

In your component:

import { useEffect, useState } from "react";
import { auth, signInWithGoogle, getProfile } from "./firebase";
import { onAuthStateChanged } from "firebase/auth";

export default function App() {
  const [user, setUser] = useState(null);
  const [profile, setProfile] = useState(null);

  useEffect(() => onAuthStateChanged(auth, async (u) => {
    setUser(u);
    if (u) setProfile(await getProfile(u.uid));
  }), []);

  if (!user) return <button onClick={signInWithGoogle}>Sign in</button>;
  return <div>Hi {user.displayName} — profile: {JSON.stringify(profile)}</div>;
}

Run it. Click Sign in. The button opens Google's OAuth popup; you grant consent; the page now greets you by name. Drop a document at profiles/<your-uid> from the Firestore console; refresh; it shows up. That's the bundle in 30 lines.

Same thing, Postgres-shaped

One-time setup: Supabase dashboard → New project. Wait ~90 seconds for the Postgres instance. In Authentication → Providers, enable Google (paste a Google OAuth client ID + secret from GCP). In SQL Editor, create a profiles table:

create table profiles (
  id uuid primary key references auth.users on delete cascade,
  display_name text,
  created_at timestamptz default now()
);
alter table profiles enable row level security;
create policy "own profile" on profiles for select using (auth.uid() = id);

From the project settings, copy the SUPABASE_URL and SUPABASE_ANON_KEY.

In your project:

npm i @supabase/supabase-js

Create src/supabase.js:

import { createClient } from "@supabase/supabase-js";

export const supabase = createClient(
  "https://<PROJECT>.supabase.co",
  "eyJ...ANON_KEY"
);

export const signInWithGoogle = () =>
  supabase.auth.signInWithOAuth({ provider: "google" });

export async function getProfile(userId) {
  const { data, error } = await supabase
    .from("profiles")
    .select("*")
    .eq("id", userId)
    .single();
  return error ? null : data;
}

In your component:

import { useEffect, useState } from "react";
import { supabase, signInWithGoogle, getProfile } from "./supabase";

export default function App() {
  const [user, setUser] = useState(null);
  const [profile, setProfile] = useState(null);

  useEffect(() => {
    supabase.auth.getSession().then(({ data }) => setUser(data.session?.user ?? null));
    const { data: sub } = supabase.auth.onAuthStateChange(async (_e, session) => {
      const u = session?.user ?? null;
      setUser(u);
      if (u) setProfile(await getProfile(u.id));
    });
    return () => sub.subscription.unsubscribe();
  }, []);

  if (!user) return <button onClick={signInWithGoogle}>Sign in</button>;
  return <div>Hi {user.email} — profile: {JSON.stringify(profile)}</div>;
}

Run it. Same flow: click Sign in, Google OAuth popup, page greets you. Insert a row into profiles with your auth.users.id as the primary key; refresh; it appears. The shape is nearly identical to Firebase; the database underneath is Postgres.

Three short answers covering most cases

• Picking right now, don't know yet what the app becomes: Supabase. The exit cost is lower, the data model handles more shapes, and the SQL skills are universal.
• Your app is fundamentally a realtime sync product (chat, collaborative editor, live game state, multi-device presence): Firebase. Firestore's realtime-everywhere model is genuinely better than Supabase's opt-in realtime for this case.
• Your app needs joins, reports, or analytics on the data: Supabase. Fighting Firestore on this is a multi-month project; Postgres handles it as a one-line SQL query.

"Both" is rare but legitimate — use Firebase Auth + Firestore for the realtime side of your app and Supabase Postgres for the relational side. Most teams find this is more complexity than it's worth and pick one.