Migrating from Firebase to Supabase without breaking everything

In brief

• You migrate from Firebase to Supabase to get back standard SQL, avoid lock-in and make costs predictable at scale.
• Three work streams: data (Firestore → relational PostgreSQL), authentication, storage. The trickiest is the data modeling.
• You never cut the service: a staged migration, with a dual-write phase.
• Firebase remains an excellent choice to start fast: you migrate when its limits (queries, costs, relations) become a real bottleneck, not on principle.

The problem, concretely

Firebase is perfect for launching a product: real-time, auth in a few lines, zero servers to manage. Then the product grows, and three pains appear: queries you cannot make (Firestore is not relational), a bill that becomes unpredictable, and the feeling of being locked in. That is when you look at Supabase, which puts PostgreSQL at the core.

Why Supabase (and its limits)

• Standard PostgreSQL: SQL queries, relations, joins, views. No lock-in: your database is portable.
• Auth, storage, database and vector search (pgvector) in the same place, with multi-tenant RLS (see isolation per tenant).
• More legible costs at scale.

Honest nuance: Firestore keeps its strengths (ultra-simple real-time, mature mobile offline mode, scaling without thinking). If your app is mostly mobile real-time without complex relations, the migration is not necessarily justified. You migrate for real reasons, not for fashion.

The 3 work streams

1. The data (the trickiest)

Firestore stores nested documents; PostgreSQL is relational. The value (and the risk) is in the remodeling: turning collections of documents into clean linked tables. That is where an experienced eye avoids reproducing the bad schemas.

2. Authentication

Migrating accounts to Supabase Auth, preserving credentials so your users do not have to recreate an account.

3. Storage

Transferring files to Supabase Storage (or an object store), with rewriting of the references.

Without breaking the existing: dual-write

The key to a migration without interruption: a dual-write phase, where the app writes to Firebase AND to Supabase while we migrate the history in the background. We switch reads when everything is synchronized and verified, then we cut Firebase. Zero downtime, rollback always possible.

In practice

This is a frequent request I handle on a flat fee after an audit: I map your Firestore model, I design the target PostgreSQL schema, and I orchestrate the migration in stages with dual-write.

Sources

• Supabase · migrating Firebase authentication
• Supabase · migrating Firestore data