Migrate From Lovable to Your Own Supabase Project

Before you start: what to inventory before migrating Supabase

The most common reason a Supabase migration fails is discovering mid-cutover that something was missed — a missing RLS policy, a Stripe secret not copied to the new project's edge function secrets, or a storage bucket that was not included in the data dump. Complete this inventory before touching the CLI.

1. List all tables in your Lovable Supabase project — run: SELECT table_name FROM information_schema.tables WHERE table_schema = 'public';
2. List all RLS policies — run: SELECT tablename, policyname, cmd FROM pg_policies;
3. List all edge functions — check supabase/functions/ in your GitHub repo.
4. List all function secrets — in the Supabase dashboard go to Edge Functions → Manage secrets.
5. Check whether your app uses Supabase Storage (file uploads) — these are NOT included in db dump.
6. Note which auth providers are enabled (email, Google, GitHub, etc.) — you will need to re-enable them in the new project.
7. Find your Lovable Supabase project reference in Project Settings → Supabase (the alphanumeric string before .supabase.co).

What does 'own Supabase project' give you that Lovable's shared instance doesn't?

Lovable's managed Supabase instance is convenient for prototyping but limits you in ways that matter for production: shared infrastructure, no direct backup access, no point-in-time recovery, and no control over database extensions or connection poolers. Owning the project unlocks those controls.

How do I export my schema from the Lovable Supabase project?

You can export the database schema directly from the Supabase dashboard SQL editor, or use the Supabase CLI with supabase db dump to get a complete schema and data dump. The CLI approach is more reliable for large databases and preserves enum types, triggers, and function definitions that the SQL editor may truncate.

1. Install the Supabase CLI: npm install -g supabase.
2. Log in: supabase login.
3. Link to your Lovable Supabase project: supabase link --project-ref <your-ref>.
4. Dump the schema: supabase db dump --schema public > schema.sql.
5. Dump the data: supabase db dump --data-only > data.sql.
6. Review both files before importing — check for any references to Lovable-specific extensions.

How do I create a new Supabase project and import the schema and data?

Create a new Supabase project in your own organisation, then apply the schema dump followed by the data dump. The order matters: schema first to create tables and types, data second to populate them. Run both inside the Supabase SQL editor or via the CLI connected to the new project.

1. Go to supabase.com → New project. Choose your organisation and region.
2. Once the project is ready, open the SQL editor.
3. Paste and run the contents of schema.sql first.
4. Paste and run the contents of data.sql after the schema succeeds.
5. Verify row counts: SELECT count(*) FROM each critical table.
6. Update your app's VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY to the new project's values.

How do I migrate RLS policies to the new Supabase project?

Row-Level Security policies are included in the schema dump if you used supabase db dump with the default options. Confirm they exist after import by running SELECT * FROM pg_policies in the new project's SQL editor. Missing policies will allow all authenticated users to read each other's data — confirm this before going live.

1. In the new Supabase project SQL editor: SELECT tablename, policyname, cmd, qual FROM pg_policies;
2. Compare the output to the original project's policies.
3. For any missing policy, write and run the CREATE POLICY statement manually.
4. Test a row-level read using the new project's anon key before pointing any live traffic there.

How do I redeploy Supabase edge functions to the new project?

Edge functions live in your codebase under supabase/functions/. Redeploying them to the new Supabase project is a single CLI command — but you must also copy any secrets the functions use (such as Stripe webhook keys) from the old project's function secrets to the new one, or the functions will fail silently on first call.

1. In your local repo: supabase link --project-ref <new-project-ref>.
2. Deploy all functions: supabase functions deploy.
3. In the old Supabase dashboard, note all secrets under Edge Functions → Manage secrets.
4. In the new Supabase dashboard, add the same secrets under Edge Functions → Manage secrets.
5. Invoke each function from the new project URL and confirm it returns the expected response.

What happens to auth users and password hashes?

Supabase does not export auth.users password hashes through any public API — the hashes are managed by the GoTrue server and intentionally withheld from exports. This means users cannot log in with their existing passwords after you move them to a new Supabase project. The only safe approach is to trigger a password-reset email for every user before the cutover date.

How do I migrate Supabase Storage buckets?

Supabase Storage file uploads are not included in the db dump and must be migrated separately. The safest approach is to download all files from the old bucket using the Supabase client or the dashboard, then upload them to the new project's bucket before DNS cutover. For large buckets, use a script to automate the transfer.

1. In the old Supabase project, go to Storage and list all buckets and their contents.
2. Use the Supabase client or supabase storage CLI to download files: supabase storage cp --experimental -r ss:///old-bucket/ ./local-backup/
3. In the new Supabase project, create matching buckets with the same names and access policies.
4. Upload files: supabase storage cp --experimental -r ./local-backup/ ss:///new-bucket/ (linking to the new project first).
5. Verify file counts match between old and new buckets before cutover.

How do I roll back if the Supabase migration breaks?

Keep the old Supabase project running and your app pointing to it until the new project passes a full smoke test. The rollback plan is to revert your environment variables to the old project's URL and anon key — a change you can make in minutes in Vercel, Cloudflare, or Netlify without touching DNS.

1. Keep both Supabase projects active until migration is confirmed stable.
2. Store the old VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY somewhere accessible during cutover.
3. If something breaks after switching env vars, restore the old values in your host's dashboard and trigger a redeploy.
4. A redeploy with the old env vars typically takes 60–90 seconds on Vercel and Netlify — far faster than a DNS rollback.
5. Do not delete the old Supabase project until the new one has been stable for at least two weeks.

Post-migration smoke test for Supabase

After switching your app to the new Supabase project, verify every data path and auth flow before considering the migration complete. A passing connection is not the same as correct data — RLS policies, storage bucket policies, and edge function secrets can all silently fail without returning an obvious error.

1. Sign in with an existing user account — confirm session starts and persists.
2. Read data from each critical table — confirm row counts and content match the old project.
3. Write a row to a critical table — confirm the write succeeds and RLS allows it for the correct user.
4. Try reading another user's data with the authenticated session — confirm RLS blocks it.
5. Invoke each edge function and confirm it returns the expected response (not a 500 from a missing secret).
6. If your app uses Storage, load a file from the new bucket and confirm it renders correctly.
7. Confirm auth providers (email, OAuth) work by completing a full sign-up and sign-in flow.