Skip to content
Migrator
Migrate

Lovable to Supabase Migration Errors and How to Fix Them

Six problems cause almost every failed Lovable to Supabase migration. Find your error below, check the likely causes and follow the fix.

Foreign key violation when importing table data

What you see: Error like: insert or update on table "comments" violates foreign key constraint "comments_post_id_fkey".

Likely causes

  • A child table was imported before its parent table, so the referenced row does not exist yet.
  • The table references auth.users(id) and your users have not been imported yet.
  • A CSV file is missing rows that other tables point to.

How to fix it

  • Import parent tables first. The migrator reads your foreign keys and sorts the tables for you; by hand, start with tables that reference nothing.
  • If a column references auth.users, import your auth users before that table.
  • Compare row counts of parent tables with the source to make sure no rows are missing.
  • For circular references, import the table with the foreign key relaxed (set the constraint to DEFERRABLE) or load in two passes.

Duplicate key value violates unique constraint

What you see: Error like: duplicate key value violates unique constraint "profiles_pkey".

Likely causes

  • You ran the same import twice, so the rows already exist.
  • A trigger on auth.users already created the profile rows, and your CSV tries to insert them again.
  • Two CSV files were mapped to the same table.

How to fix it

  • If a previous run partly succeeded, truncate the affected table and import again from scratch.
  • If a trigger creates profile rows, import the CSV first with the trigger disabled, or update the existing rows instead of inserting.
  • Check the mapping table so each CSV maps to a different table.
SQL: clear a table before re-importing (careful, deletes rows)
truncate table public.profiles restart identity cascade;

Row Level Security is blocking data

What you see: The import succeeds but the app shows empty lists, or inserts from the app fail with a permission error.

Likely causes

  • RLS policies were not created because a migration file failed or was skipped.
  • Policies reference functions (like has_role) that were not created yet.
  • The app uses the new publishable key but the policies still expect a different role.

How to fix it

  • In the Supabase dashboard open Authentication → Policies and confirm each table has the policies from your migration files.
  • Re-run the schema migration; skip safe 'already exists' messages.
  • Test as a logged-in user, not only as the service role, because the service role bypasses RLS and hides the problem.
SQL: list policies and RLS status
select schemaname, tablename, policyname, cmd from pg_policies where schemaname = 'public' order by tablename;
select relname, relrowsecurity from pg_class where relnamespace = 'public'::regnamespace and relkind = 'r';

Users can't log in after the migration

What you see: Invalid login credentials for accounts that worked before.

Likely causes

  • User ids or password hashes were not copied exactly.
  • The auth.identities row for email sign-in is missing.
  • The user signed in with Google before and has no password.
  • The app still points at the old project, or the Site URL and redirect URLs are wrong.

How to fix it

  • Compare one user's id and encrypted_password between the old and new projects.
  • Check that auth.identities has an 'email' row for the user.
  • Re-enable Google (or the provider used) under Authentication → Sign In / Providers.
  • Verify your .env values and set the Site URL in Authentication → URL Configuration. See Connect your Lovable app to your new Supabase project.
SQL: check a user and identity
select u.id, u.email, left(u.encrypted_password, 7) as hash_prefix, i.provider
from auth.users u left join auth.identities i on i.user_id = u.id
where u.email = 'person@example.com';

Missing supabase/migrations folder

What you see: The repository or ZIP has no supabase/migrations files, so there is no schema to replay.

Likely causes

  • The project was never synced to GitHub, or an older sync is being used.
  • The structure exists only in the live database.
  • The ZIP was downloaded from the wrong branch.

How to fix it

  • Make sure you downloaded the default branch of the correct repository. See How to sync your Lovable project to GitHub.
  • Use the SQL query in the export guide to rebuild CREATE statements from the live database, then paste the result into the migrator.
  • Review the rebuilt schema for sequences and extensions, which are not included.

Edge function secrets are missing

What you see: A function returns 500 errors, or logs show a variable is undefined or an API key is invalid.

Likely causes

  • Secrets are never exported from Lovable, so the new project has none.
  • A secret was set with a typo in its name.
  • The function was not redeployed after secrets changed.

How to fix it

  • Search your function code for Deno.env.get( to list the exact names.
  • Set each one again with supabase secrets set NAME=value, then check with supabase secrets list.
  • Redeploy the function and check its logs in the Supabase dashboard. See Deploy Lovable edge functions on your own Supabase.
Terminal
supabase secrets set MY_KEY=value
supabase secrets list
supabase functions deploy my-function

Still stuck? Read the complete migration guide or join the done-for-you waitlist.

Need help?