Supabase vs Firebase

At a glance

1. The billing unit decides what code you may write

Supabase sells a machine. You rent a Postgres instance, a disk and a connection ceiling, and reads inside them are free. Firebase sells events. Every document read, write, index batch and listener update is a line on the invoice, with a daily free quota on top.

What each philosophy forbids:

• Firestore forbids JOINs. A relation becomes duplicated fields or an extra round trip, and the extra reads are billed.
• Supabase forbids cheap concurrency. The $10 Micro instance stops at 60 direct and 200 pooled connections. The ceiling is purchasable rather than absolute — 12,000 pooled connections at $3,730 — but you buy it per project.

2. A listener is a meter, not a subscription

A listener is not a free subscription. Firestore bills a read each time a document enters or updates in a live listener's result set, and one more when a change pushes it out. The meter runs while nobody clicks. Don't pick Firestore for a screen that stays open all day.

Take 50 users, each watching 100 documents that change 20 times a minute:

users, docs, changes_per_min = 50, 100, 20
reads = users * docs * changes_per_min * 60 * 24 * 30
print(reads)                   # 4.32B events, zero clicks
print(reads / 100_000 * 0.03)  # 43,200 x $0.03, before free quota

That is a gross read charge at the us-central1 rate, before free-quota adjustments. One Pro Micro project costs $25/month inside its quotas — which says nothing about whether that instance can carry the load, only that the bill stops tracking the watching. Reconnects make it worse:

• Offline persistence off: every reconnect is billed like a brand-new query.
• Persistence on but disconnected for more than 30 minutes: same bill.

3. On Supabase the ceiling is capacity, not a per-read meter

Postgres Changes is a database event stream, and you opt in per table:

Add a table to the publication: alter publication supabase_realtime add table your_table_name;

Nothing in that stream is metered per read. What runs out is the instance: its compute tier and its connection and pooler limits. Compute is billed per project, separately from the plan.

You stop paying for spikes and start paying for headroom. Size for peak connections: Pro's $10/month credit covers one Micro, and every extra project adds its own compute.

4. Index entry reads are the Firestore line item nobody quotes

• One read per batch of up to 1,000 index entries a query reads.
• A query with one range field pays nothing for index entries. Zero range fields are also exempt. Add a second range field and billing starts.
• count(), sum() and avg() bill index reads, with a 1-document-read minimum even at zero entries.

Firestore's own docs give the example: count() over 1,500 index entries bills 2 document reads.

Ten million plain reads cost $3.00 at the listed rate. The count() in your page header is a different bill.

Audit any query that combines two range fields before it ships.

5. Migration is a schema project with a script attached

supabase-community/firebase-to-supabase on GitHub is community tooling, not an official CLI. What it does:

1. firestore2json.js exports a collection; json2supabase.js loads it into a table. One collection, one table.
2. Fields are flattened to text, numeric, boolean or jsonb.
3. Splitting nested JSON into related tables needs custom hooks you write.

Auth is the sharper edge. firestoreusers2json and import_users move users, importing hashes with Firestore's SCRYPT parameters (base64_signer_key, base64_salt_separator, rounds, mem_cost).

Verifying an existing Firebase password on first login needs a middleware the repo itself marks work in progress. The AWS Lambda variant is listed as TBD.

Until that middleware exists, plan for blocked logins at cutover and decide in advance whether you force a password reset.

6. Pick by bill shape first, then by blockers

Choose Supabase when modeled Firestore charges exceed the plan and compute cost and the workload fits the selected tier and quotas. Keep Firestore when all free allowances fit:

• 50,000 reads, 20,000 writes and 20,000 deletes per day.
• 1 GiB stored, 10 GiB/month outbound; one free database per project.

Check today, in this order:

1. Multiply listeners × documents per listener × changes per minute × (60 × 24 × 30) minutes, then × $0.03 per 100,000.
2. Find every hot-path query with two range fields or a count().
3. On Supabase, compare peak database connections to Micro's 60 direct / 200 pooled.
4. Check whether first-login existing-password verification blocks migration.

Cost arithmetic at volume

These are computed from the published unit prices, not measured. Each row prints its own formula, so you can replace our assumption with your traffic and redo it.

Decision matrix

Rows are the situation you are actually in. Pick the row before you read the pricing page again.

Code and configuration

// Relational read in one round trip. Free-tier note:
// the nested select is a JOIN, so 50 comments cost 0 extra reads.
const { data, error } = await supabase
  .from('posts')
  .select('id, title, comments(id, body, user_id)')
  .eq('published', true)
  .order('created_at', { ascending: false })
  .limit(20);
// Here it breaks: anon key + missing RLS policy = empty array, not an error.
if (error) throw error;

// N+1 by design: comments are a second query per post.
const q = query(collection(db, 'posts'), where('published', '==', true));
const snap = await getDocs(q);           // 20 reads
for (const doc of snap.docs) {
  // Denormalise, or pay: 20 more queries = 20 more billed reads
  const comments = await getDocs(collection(doc.ref, 'comments'));
}
// Here it breaks: a live listener on this collection bills a read on
// every document update, for every listener, for as long as the tab is open.

What you gain, what you give up

Migration path

Common questions

Sources & verification

Prices and limits were read from these pages on 2026-11-10. Vendor marketing claims are quoted as claims. Anything derived is arithmetic on the numbers below.

Keep reading