Firebase → Supabase
Move Firestore data, Authentication, Storage, security rules, Cloud Functions, triggers, indexes, realtime behavior, hosting dependencies, analytics hooks, and application clients into a relational Supabase architecture.
Should you make this move?
Both platforms have a case. Compare what you gain with what you give up before scheduling the cutover.
Firebase
- Authentication, realtime data, hosting, and mobile tooling enable very fast product delivery
- Managed infrastructure removes a large amount of operational work
- NoSQL modeling, usage-based costs, and Google-specific APIs can be difficult to unwind
- Platform-specific services can create architectural lock-in
Supabase
- PostgreSQL, authentication, storage, realtime, and edge functions offer an open backend stack
- Managed infrastructure removes a large amount of operational work
- Production scaling and service integration still demand database and infrastructure judgment
- Platform-specific services can create architectural lock-in
Supabase: PostgreSQL, authentication, storage, realtime, and edge functions offer an open backend stack. This removes a major source-side concern: NoSQL modeling, usage-based costs, and Google-specific APIs can be difficult to unwind.
What you lose: Authentication, realtime data, hosting, and mobile tooling enable very fast product delivery. What you inherit: Production scaling and service integration still demand database and infrastructure judgment.
Know the shape of the move.
This timeline assumes
- Up to 100 Firestore collections, one million documents, 100,000 users, and 100 GB of files
- Application owners can ship coordinated client and server releases.
- A production-shaped dataset and identity cohort are available for rehearsal.
- The source remains authoritative until final consistency and security checks pass.
- The migration team records evidence for every blocking verification check.
What survives the move.
“Partial” and “manual” are not footnotes. They are work that must be scheduled and verified.
| Item | Outcome | Impact | What happens | Mitigation |
|---|---|---|---|---|
| Firestore collections and nested documents | partial | critical | Supabase’s tool copies one collection to one Postgres table and flattens values into basic columns or JSONB. | Design a relational schema and stable keys before transforming each collection. |
| Firebase Authentication users and sessions | partial | critical | Apps can retain Firebase as third-party auth or migrate users separately; token and password behavior require an explicit strategy. | Choose coexistence, rolling migration, or forced reauthentication and test every provider. |
| Firebase security rules | manual | critical | Firestore and Storage rules do not become Postgres Row Level Security policies. | Translate each rule into tested RLS and storage policies before client traffic. |
| Cloud Functions, triggers, offline sync, and realtime listeners | manual | critical | Execution and client consistency models differ between Firebase and Supabase. | Port functions and rewrite client data access with concurrency, retry, and offline behavior tests. |
| Primary application data | partial | critical | Records can move while source and destination data models, types, identifiers, and constraints differ. | Design the target schema and preserve stable source IDs. |
| Nested data and relationships | partial | critical | Document nesting, references, joins, and cascade behavior require explicit transformation. | Model relationships and verify orphan, duplicate, and cascade behavior. |
| Authentication users | partial | critical | Accounts may move while password hashes, providers, MFA, verification, and sessions require separate handling. | Choose a supported rolling or one-off identity strategy. |
| Authorization and security rules | manual | critical | Source rules do not execute as destination database or storage policy. | Translate into least-privilege policies and test every role. |
| File and object storage | partial | critical | Objects, metadata, signed URLs, paths, and access policies require separate copying. | Copy with checksums and verify authorized and anonymous access. |
| Serverless functions and triggers | manual | critical | Runtime APIs, triggers, regions, retries, and secrets differ. | Port and integration-test every function and failure path. |
| Realtime subscriptions | partial | high | Event ordering, payloads, filters, reconnects, and delivery guarantees differ. | Rewrite clients and test concurrency, disconnect, and replay behavior. |
| Offline behavior and local cache | lost | high | Source client SDK persistence does not automatically exist in the destination stack. | Choose and test an explicit offline and conflict strategy. |
Where each thing goes.
| Source | Destination | Method | Notes |
|---|---|---|---|
| Firebase project | Supabase project | manual | Record regions, environments, owners, and billing. |
| Collection, document, or record | Destination table and row | transform | Preserve source IDs and types. |
| Nested object or reference | Column, JSON, or relation | transform | Choose explicit relational semantics. |
| Authentication user | Destination auth user or federated identity | transform | Preserve verification and provider identifiers where supported. |
| Security rule | Destination authorization policy | manual | Translate and test every role and path. |
| Storage object | Destination storage object | transform | Preserve path, metadata, checksum, and access. |
| Function or trigger | Destination function, hook, or scheduled job | manual | Port retries, idempotency, and secrets. |
| Realtime listener | Destination subscription | transform | Rewrite payload and reconnect handling. |
| Index and query | Destination index and query | manual | Benchmark production-shaped workloads. |
Make the move recoverable.
Create the source-of-truth backup
Preserve Firebase data, configuration, and operating evidence before any destination write.
- Export Firebase data, schema, identities, security rules, storage, functions, indexes, configuration, and logs.
- Record counts, checksums, sizes, auth states, policies, and query baselines.
- Capture client versions, SDK configuration, integrations, backups, and recovery procedures.
- Hash raw exports and transform working copies only.
Proof to capture: A signed manifest reconciles every scoped record class, runtime dependency, export file, count, and hash.
Target schema and identity map
Translate records, relationships, users, and stable IDs.
- Inventory source values and exceptions.
- Define explicit destination mappings.
- Reject unmapped critical records.
Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.
Policy and client compatibility layer
Preserve authorization and support controlled client rollout.
- Normalize encoding, dates, identifiers, and blanks.
- Run a representative pilot.
- Reconcile accepted, rejected, and transformed rows.
Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.
The things most likely to hurt.
These are operating limits. Treat every “Stop if” condition as a blocked migration, not a suggestion.
Data-model transformation changes meaning
Nested values, identifiers, timestamps, or relationships differ after import.
- Consequence
- Applications read incorrect or incomplete data.
- Mitigation
- Use deterministic transforms and record-level reconciliation.
Stop if: Any critical invariant fails.
Authorization is weaker than the source
A destination role can read or write unauthorized rows or objects.
- Consequence
- Sensitive data is exposed or changed.
- Mitigation
- Default-deny and test every policy with real client identities.
Stop if: Any unauthorized operation succeeds.
Old and new backends both accept writes
Client versions or triggers write to different systems.
- Consequence
- Data diverges permanently.
- Mitigation
- Use version gates, a write freeze, or an approved dual-write reconciliation design.
Stop if: Unreconciled writes appear in either system.
Do the work in this order.
- Days 1–3 · inventory
Inventory and decisions
6–12 hours active2–3 days elapsedOwner review waiting- Inventory Firebase data, features, users, domains, and integrations.
- Approve scope, owners, mappings, and exclusions.
Depends on: Firebase and Supabase administrator access
Stop / go checkpointExport?
Go when: Every critical item has an owner and disposition.
Stop when: Consent, billing, access, or system ownership is unclear.
- Days 3–5 · backup
Backup and reconcile
5–10 hours active1–3 days elapsedExport processing waiting- Create immutable exports and configuration evidence.
- Reconcile counts, totals, and hashes.
Depends on: Approved inventory
Stop / go checkpointTransform?
Go when: Source totals and export manifests agree.
Stop when: Any critical dataset or configuration is absent.
- Days 5–12 · pilot
Map and pilot
10–35 hours active3–8 days elapsedDestination processing and review waiting- Configure Supabase and transform representative data.
- Run a pilot containing normal records and every critical edge case.
Depends on: Verified backup
Stop / go checkpointScale?
Go when: Pilot mappings, behavior, access, and evidence pass.
Stop when: Any critical check fails or produces unexplained variance.
- Days 10–20 · cutover
Final delta and switch
5–25 hours active1–5 days elapsedDNS, import, or sync propagation waiting- Freeze production writes in Firebase.
- Apply the final delta, switch ownership, and run blocking checks.
Depends on: Passed pilot and approved rollback
Stop / go checkpointOpen production?
Go when: Counts reconcile and one destination system owns production.
Stop when: A source writer remains active or a blocking check fails.
- Days 12–40 · observe
Observe and close
3–18 hours active3–10 days elapsedOperating-cycle evidence waiting- Monitor one complete operating cycle.
- Sign the verification report and close rollback only after stability.
Depends on: Verified cutover
Stop / go checkpointClose rollback?
Go when: No trigger occurs during the agreed observation period.
Stop when: Data, access, delivery, routing, or business results regress.
Cut over with a way back.
Cutover
Make Supabase the only production system without losing the final Firebase delta.
- Freeze production writes and scheduled actions in Firebase.
- Export, transform, and reconcile the final delta.
- Apply the approved delta to Supabase.
- Switch domains, forms, integrations, sending, or sync ownership as applicable.
- Run every blocking verification check and keep the source intact.
Proof to capture: Supabase owns production, totals reconcile, and every blocking check has durable evidence.
Rollback
Return production ownership to Firebase without losing destination-era changes.
- Stop new writes and scheduled actions in Supabase.
- Restore the prior Firebase routing, forms, integrations, sending, or sync ownership.
- Export the Supabase post-cutover delta.
- Review and apply safe destination-era changes to Firebase.
- Run the same blocking checks against the restored source.
Proof to capture: Firebase again owns production with current data and no duplicate destination action.
- Unexplained critical count or value variance
- Missing or exposed critical data
- Duplicate production action
- Failed access, routing, delivery, or integration check
- A critical feature has no safe destination replacement
Prove the migration worked.
Every blocking check must pass. Capture the evidence before cleanup begins.
| Pass | ID | Check | Method | Expected result | Evidence |
|---|---|---|---|---|---|
V-01Blocking | Record reconciliation | Compare counts, checksums, aggregates, and stratified records. | Every scoped record is accounted for. | Data ledger. | |
V-02Blocking | Types and relationships | Test constraints, identifiers, nulls, dates, arrays, and cascades. | All critical invariants hold. | Schema report. | |
V-03Blocking | Authentication states | Test every provider, verification, reset, MFA, and session path. | Users can authenticate only as approved. | Auth matrix. | |
V-04Blocking | Data and storage policy | Run allowed and denied operations for every role. | Every policy defaults and resolves correctly. | Policy test report. | |
V-05Blocking | Object coverage | Compare paths, sizes, hashes, metadata, and signed access. | Every required object is durable and correctly protected. | Storage manifest. | |
V-06Blocking | Triggers and side effects | Run success, retry, timeout, duplicate, and failure cases. | Idempotent approved outcomes. | Function log. | |
V-07Blocking | Query, realtime, and offline behavior | Run supported client versions through representative workloads. | Correct reads, writes, events, and recovery. | Client matrix. | |
V-08Blocking | Backup and rollback | Restore a destination backup and execute the rollback rehearsal. | Recovery objectives and integrity pass. | Recovery report. |
Remove the scaffolding safely.
Safe after: One complete operating cycle, at least seven stable days, and owner sign-off on every blocking check.
- Create final Firebase exports and archive verification evidence.
- Revoke temporary credentials, API keys, webhooks, and elevated roles.
- Remove obsolete embeds, forms, jobs, integrations, and DNS records.
- Keep the source intact through the approved retention window.
- Cancel paid plans only after billing, legal, and recovery review.
- Schedule the next Supabase backup, access, and migration-playbook review.
When the plan met reality.
First-hand accounts are preferred. Vendor case studies are labeled, and every note below is an editorial paraphrase—follow the link for the full context.
The creator of UnwindHR moved authentication, Firestore data, storage, and application code to Supabase during a planned weekend outage. The author designed relational schemas first, refactored and tested before cutover, then took a final Firebase snapshot. Passwords and original user IDs did not transfer through the chosen auth path, and nested Firestore collections required a custom JSON export and transformation script.
- Design the relational schema and refactor application queries before taking the final production snapshot.
- Plan explicitly for password resets and preserve legacy Firebase IDs in temporary mapping columns where references may remain.
- Top-level export tooling was insufficient for nested Firestore collections, so custom traversal and splitting were required.
- A short maintenance window simplified consistency, but only because most conversion work had already been rehearsed.
The Fleeting Notes creator describes moving more than 1,000 users while preserving a live service and user-specific data such as Stripe customer references and encryption keys. Rather than treating the database copy as the whole job, the migration used application logic and database webhooks to retrieve legacy Firebase values when users crossed into the new system.
- Identify identity-linked secrets and billing references that need a controlled handoff, not just a bulk database copy.
- Test the first-login path for existing users because lazy migration logic becomes part of the production cutover.
- A seamless user transition required coordination between authentication, billing identifiers, encrypted data, and database triggers.
- Keeping targeted access to legacy Firebase data reduced the need for a single high-risk all-at-once conversion.
Built to be reviewed.
Tested 2026-07-19. Next scheduled review: 2026-10-19.
- Supabase: migrate Firestore dataAccessed 2026-07-19
- Supabase: use Firebase AuthAccessed 2026-07-19
- Supabase: migration guidesAccessed 2026-07-19