Migrate from Supabase to Firebase

There is no single Supabase to Firebase migration. There are two, and they cost wildly different amounts. Firestore is a document store, so moving to it means giving up joins, foreign keys, and SQL, which is a rewrite of your data layer rather than a port. Firebase SQL Connect, generally available since April 2025 and previously called Data Connect, is backed by Cloud SQL for PostgreSQL, so it is a Postgres to Postgres move with a GraphQL layer replacing PostgREST. Pick the path before you touch anything, because they share almost nothing.

Choose the path first

Ask one question: does your application rely on SQL?

If the answer is yes in any meaningful way, and for a Supabase project it usually is, then Firestore is not a migration target. It is a redesign. Take the SQL Connect path and accept a monthly instance cost, or reconsider whether you should be moving to Firebase at all rather than to Neon, which keeps Postgres without the GraphQL layer.

If your data is genuinely document-shaped, if you were mostly using Supabase as a key-value store with realtime, and if you never wrote a join you cared about, Firestore is cheaper and its free tier is better.

The cost line is the one that changes decisions. Supabase's free tier has no instance fee. SQL Connect always has one after the trial, so the floor is higher than what you are leaving even though the ceiling is higher too.

What Firestore actually takes away

If you are considering Firestore, know exactly what you are giving up. These are not rough edges, they are absences.

• No joins. You denormalize, or you make several round trips and assemble in application code.
• No foreign keys or referential integrity. Nothing stops an orphaned reference. That invariant becomes your job.
• No server-side SQL aggregation beyond count, sum, and avg aggregation queries.
• No arbitrary `ORDER BY`. Ordering requires the field to be indexed and consistent with your filters.
• No `LIKE` and no full text search. You add Algolia, Typesense, or Elastic, which is another vendor and another bill.

The query limits bite in ways that are hard to predict from the documentation. Every non-trivial query needs a hand-declared composite index, and a database is capped at 1,000 composite indexes with billing enabled, or 200 without. Range and inequality filters across multiple fields are supported now but cap at ten such fields per query, and they require carefully ordered composite indexes with equalities first.

The worst one for correctness: indexed values are truncated at 1,500 bytes. Past that, query results become quietly inconsistent rather than raising an error. Transactions exist but are document-scoped, with a 270 second limit, a 60 second idle expiry, and 500 field transformations per commit. Documents cap at 1 MiB.

None of this makes Firestore a bad database. It makes it a different one, and a Supabase schema does not survive contact with it unchanged.

The SQL Connect path

SQL Connect is the comparison worth making, because the underlying engine is the same Postgres you already run. You define a schema in GraphQL, Firebase provisions Cloud SQL behind it, and you get generated typed SDKs for your clients.

What changes is the access layer rather than the data. Supabase gives you PostgREST plus row level security, where authorization lives in the database as policies reading JWT claims. SQL Connect gives you a GraphQL schema with its own authorization directives. Your RLS policies do not port. You express the same rules in a different place, which is real work but is rule-for-rule translation rather than redesign.

Pricing runs at 250,000 operations per month free on Blaze, then $0.90 per million operations, plus the Cloud SQL instance itself. The Spark plan caps at 8,300 operations per day, which is a prototype allowance rather than a production one.

Dump and restore is the same shape as any Postgres move. Take public only, use --no-owner --no-acl because Supabase's roles will not exist on the destination, and match the major version.

Auth is the easy part

This is where Firebase is genuinely strong, and where the migration is close to free.

Firebase Authentication allows 50,000 monthly active users on the free Spark plan, matching Supabase exactly. More importantly, the password migration is solved rather than worked around. Supabase stores standard bcrypt hashes with a per-user salt in auth.users.encrypted_password, and the Firebase CLI imports bcrypt directly:

firebase auth:import users.json --hash-algo=BCRYPT

No hash key is needed for bcrypt. No user resets a password, and no lazy migration layer is required. The importer also handles Scrypt, StandardScrypt, several HMAC variants, MD5, SHA family, PBKDF_SHA1, and PBKDF2_SHA256, so it is a good destination from almost anywhere.

There is no export button in the Supabase dashboard. Pull the rows with a direct query against the auth schema and treat that file as a credential, because that is exactly what it is.

Two limits to plan around. Enterprise SAML and OIDC connections have their own free allowance of just 50 monthly active users, which is a fraction of the general pool and catches B2B teams by surprise. Phone authentication is billed per SMS rather than counted against the MAU allowance. For how this compares to the dedicated identity providers, see Firebase Auth alternatives and Replace Supabase Auth.

Storage moves cleanly

Supabase Storage is S3 protocol compatible. Enable the S3 connection in your Storage settings and it authenticates with AWS Signature Version 4, implementing bucket operations, object get, put, delete and copy, multipart upload, and both ListObjects versions. Supabase's own documentation says it works with almost any S3 client.

Firebase Cloud Storage buckets are Google Cloud Storage buckets, so the practical path is a sync between an S3 remote pointed at Supabase and a GCS remote, then repointing Firebase at the destination bucket. There is no single official one-shot tool for this pairing, so a general-purpose sync utility is the pragmatic answer.

One gap to note before you rely on it: Supabase Storage has no S3 versioning. If you were counting on version history as a safety net during the copy, it is not there.

Cloud Storage for Firebase gives 5 GB on the free plan with 1 GB of downloads per day, against Supabase's 1 GB of storage and 5 GB of egress. Firebase is the more generous side on storage volume. If egress is what actually hurts, neither is the right answer and Cloudflare R2 charges nothing for it at any volume.

Realtime and functions

Supabase Realtime and Firestore's realtime listeners solve the same problem with different models. Supabase streams Postgres changes. Firestore pushes document snapshots to subscribed clients, which is a more natural fit if you are taking the Firestore path and a gap if you are taking SQL Connect, where you would poll or add a separate channel.

Edge Functions map onto Cloud Functions reasonably well, but the runtimes differ. Supabase Edge Functions run Deno. Cloud Functions run Node, Python, and several others. Anything using Deno-specific APIs or npm-via-Deno imports needs rewriting rather than copying, and the free allowance is 2 million invocations per month.

Sequence the work

Do these in order and do not overlap them. The failure mode of a combined migration is that you cannot tell which system broke.

1. Decide Firestore or SQL Connect, and write the decision down with the reasoning. Changing your mind halfway is the expensive outcome.
2. Move auth first. It is the lowest-risk piece because bcrypt imports cleanly, and it is independently reversible.
3. Move storage second. Sync, verify object counts and a sample of checksums, then repoint.
4. Move data last, because it is the piece with the most surface area and the least reversibility.
5. Keep Supabase running through a full billing cycle, so rollback stays a configuration change.

If step one lands on Firestore and step four turns into a schema redesign, stop and reconsider. A rewrite of your data layer to reach a free tier is rarely the cheapest way to save money, and the alternatives are laid out in Supabase alternatives compared.