Task. Apps built in Lovable keep their data in Lovable Cloud. An owner who wants the database in a Supabase project of their own needs the tables, the rows and the user accounts moved, so that nobody has to sign up again.
Export. Lovable exports the whole database as one pg_dump file, at most once a day. The file is binary and compressed, so the SQL Editor can't take it as it is. We split it into schema, data and permissions, then cut each part into pieces of about 15 KB, because a larger paste stalls the editor. The pieces ran in order in the new project, without pg_restore.
Check. Every number was counted on both sides with SQL queries. The schema matched one to one: 30 tables, row level security on 15 of 15, 15 policies, 20 foreign keys, 6 functions, 1 trigger and 1 storage bucket. The rows matched too: bookings 77 of 77, clients 25 of 25, dogs 26 of 26, waitlist 9 of 9, messages 25 of 25. The user moved with a password hash identical to the original, and the app's own database function ran on the new project and filled the demo tables.
By hand. Scheduled jobs (pg_cron) live in a system schema and have to be recreated. Grants for Lovable's internal role don't exist in Supabase, so they are skipped. Server code that uses the service key on Lovable's hosting needs new keys wherever the site runs, and the owner sets those. The grants for the API roles are kept, which matters after Supabase's change of 30 October 2026.
Scope. The site itself was not switched to the new database. On a real project that is the last step, done in the owner's own Supabase account and hosting. The owner types the database password and keys, so they never reach us.