Moving from Firebase to Da8a

1. Plan your tables

Map each Firestore collection to a table. Fields you filter or join on become columns; nested or irregular data can live in a jsonb column until you’re ready to model it. Subcollections usually become their own tables with a foreign key to the parent.

create table posts (
  id text primary key,          -- keep the Firestore document id
  author_id uuid references auth.users,
  title text not null,
  data jsonb                    -- anything you haven't modelled yet
);
alter table posts enable row level security;

2. Export your data

Read each collection with the Firebase Admin SDK in a script and write it out as JSON, or use Google Cloud’s managed Firestore export. Download Cloud Storage files with Google’s command-line tools.

3. Load it into Da8a

Run a script that inserts the rows with supabase-js and your project’s service key, in batches. Upload files to Da8a Storage buckets with supabase.storage.from(bucket).upload().

import { createClient } from '@supabase/supabase-js'
const admin = createClient(PROJECT_URL, SERVICE_KEY)

for (const batch of chunks(posts, 500)) {
  const { error } = await admin.from('posts').insert(batch)
  if (error) throw error
}

4. Move your users

Firebase Auth users can be exported with the Firebase CLI. Whether existing passwords carry over depends on the password hash format, so plan for users to set a new password or sign in with a magic link the first time. Google and GitHub sign-in work again once you enable those providers under Auth.

5. Rewrite rules and functions

• Security Rules → Row Level Security. Rewrite each rule as a SQL policy; auth.uid() replaces request.auth.uid.
• Cloud Functions → edge functions. Port each function to a Deno handler and set its secrets. See Edge functions.
• App code → supabase-js. Replace Firebase SDK calls with supabase-js queries, auth, realtime and storage calls. See the client guide.