Need more than a raw Firebase export? WZ-IT delivers a Firebase-to-Supabase migration across data modelling, Auth, Storage, Functions, testing and cutover.
A Firebase-to-Supabase migration is not a swap between two identically structured databases. Firebase combines several managed services and uses the document-oriented Firestore model. Supabase is built around relational PostgreSQL and enforces access through database grants and Row Level Security.
The largest part of the work is therefore often translating the application architecture, not copying bytes.
Which Firebase services are in use?
Inventory the actual estate before designing the target:
- Cloud Firestore or Realtime Database
- Firebase Authentication and external providers
- Firebase Storage
- Cloud Functions and triggers
- Firebase Hosting
- Cloud Messaging and push notifications
- Analytics, Crashlytics and Remote Config
- App Check
- extensions and connected Google Cloud services
Supabase does not replace every service one for one. Messaging, analytics or remote configuration may need complementary platforms or custom services.
Firestore and PostgreSQL think differently
Firestore stores documents in collections and subcollections. Relations often use embedded objects, identifiers or duplicated data. PostgreSQL uses tables, primary and foreign keys, constraints and joins.
A simple “one collection equals one table” mapping can work for basic data. Complex applications need design decisions:
| Firestore pattern | Possible PostgreSQL target |
|---|---|
| Embedded object | Separate table, JSONB or columns |
| Subcollection | Dependent table with a foreign key |
| Duplicated reference data | Normalised relation or deliberate materialisation |
| Array of IDs | Join table or typed array |
| Dynamic document fields | Defined columns or bounded JSONB |
| Compound Firestore query | SQL query with suitable indexes |
Design the target around real read and write paths, not only the export format.
Export and transform data
Supabase provides official Firebase migration resources and community tools. The documented Firestore path exports collections to JSON, transforms them and imports them into PostgreSQL.
A production migration includes:
- consistent Firebase export
- mapping documents to the target schema
- transforming IDs, timestamps and references
- importing in dependency order
- checking rows, relations and constraints
- comparing critical business queries
Large or actively written data sets also need a strategy for changes between the initial export and cutover.
Firebase Auth to Supabase Auth
The official Auth migration guide documents two tools: Firebase users are exported to JSON and then imported into auth.users. Firebase password-hash parameters need to be preserved.
Also review:
- email and phone verification
- linked OAuth identities
- custom claims and roles
- disabled users
- MFA
- password reset and email templates
- active sessions and tokens
Test representative accounts for every provider. Some edge cases may require a planned password reset or a first-login transition flow.
Security Rules become grants and RLS
Firebase Security Rules and Supabase RLS have different models. Translate rules semantically rather than syntactically.
For each table, define:
- Which operations may
anonperform? - Which operations may
authenticatedperform? - Which rows belong to the current user or tenant?
- Which server processes need elevated rights?
- Which relations must a policy check?
PostgreSQL checks grants first and policies afterwards. Both need to be correct. service_role bypasses RLS and belongs only in controlled server-side components.
Firebase Storage to Supabase Storage
The official Storage migration guide uses two stages: download files from Firebase and then upload them to Supabase.
Move and verify:
- bucket structure and object paths
- files and content types
- metadata
- public or private visibility
- signed URLs and their consumers
- Storage RLS policies
After upload, compare object counts, sizes and samples or checksums. Existing Firebase download URLs do not automatically continue working.
Reassign Cloud Functions and triggers
Firebase Functions can move to different targets:
- Supabase Edge Functions
- PostgreSQL triggers and database functions
- webhooks
- queue or workflow systems
- standalone backend services
Runtime, authentication, secrets, triggers and error handling change. A function should not be ported blindly when PostgreSQL can perform the operation transactionally and more simply.
Adapt the application and SDK
Frontend and backend use different clients, URLs and error objects after migration. Review:
- initialisation and environment variables
- data queries and pagination
- Realtime listeners
- auth state and token refresh
- uploads and download URLs
- offline behaviour
- server-side administrative access
- push notifications and remaining Firebase services
A parallel phase with automated and manual user-journey tests is safer than an immediate production replacement.
Cut over with a clear boundary
Before switching, define:
- the last Firebase write point
- final data and Storage sync
- behaviour of active sessions
- release of the new application version
- treatment of old clients
- rollback window and post-cutover data
Retire Firebase resources only after acceptance. Preserve exports and backups for the agreed period.
