How to Migrate From Firebase to Supabase Without Rewriting Code

The most common reasons: unpredictable Blaze plan costs (Firestore charges per read/write), NoSQL limitations for relational data, vendor lock-in concerns with proprietary APIs, open-source preference (Supabase is self-hostable), and SQL familiarity. The migration is doable but requires careful planning.

Before migrating, catalog every Firebase service you use: Firestore (all collections and document structures), Firebase Auth (user count, auth providers in use), Cloud Storage (bucket inventory and total size), Cloud Functions (all functions and triggers), and other services (Remote Config, Messaging, Analytics). Prioritize: Firestore, Auth, and Storage are essential. Cloud Functions can be replaced with Supabase Edge Functions.

Firestore stores nested documents; PostgreSQL uses relational tables. Export from Firestore using the Firebase Admin SDK or gcloud firestore export. Design your PostgreSQL schema based on document structures — flatten nested documents into related tables with foreign keys. Transform data with a script that converts Firestore documents into PostgreSQL rows, handling type conversions (Timestamps, GeoPoints, etc.). Import into Supabase using the SQL editor, psql, or REST API for bulk inserts.

Export Firebase users using the Admin SDK's listUsers() method. Import into Supabase using its admin API. Important: you cannot export Firebase password hashes in a format Supabase can import directly. Users will need to reset their passwords. Implement a 'password reset required' flow for migrated users.

For OAuth users (Google, GitHub), configure the same providers in Supabase. Users can sign in normally — Supabase creates new auth records on first login.

List all files in Firebase Storage buckets using the Admin SDK. Download files to a server using gsutil or a custom script. Upload to Supabase Storage using the client library or REST API. Update all database records that reference Firebase Storage URLs to point to Supabase Storage URLs. For large volumes (10GB+), run the migration script on a server close to both services.

Migrations are painful, risky, and time-consuming. ShipStack eliminates future migrations by abstracting the provider layer. Instead of replacing Firebase SDK calls with Supabase SDK calls (trading one lock-in for another), replace them with ShipStack REST API calls that work with any provider.

Your migration path becomes: set up ShipStack with Supabase as your provider, replace Firebase SDK calls with ShipStack REST calls, migrate your data to Supabase. You're done — and you'll never need to migrate again.

The cost of migration isn't just engineering time — it's the opportunity cost of not building features. Use an abstraction layer from day one and make provider choice a configuration decision, not an architectural one.