Bramblewash · database move
From Lovable Cloud to its own Supabase project, checked table by table
Schema, data and users with their password hashes, moved through the new project’s SQL Editor. The left column is the original project and its export, the right one is a query to the new database.
- Lovable Cloud exportpg_dump, PostgreSQL 17.6
- New Supabase projectSQL Editor, in parts of 15 KB
Schema
| What | Original | New | matches |
|---|---|---|---|
| Tables | 30 | 30 | matches |
| Row level security on | 15 | 15 | matches |
| Policies | 15 | 15 | matches |
| Foreign keys | 20 | 20 | matches |
| Functions | 6 | 6 | matches |
| Triggers | 1 | 1 | matches |
| Storage buckets | 1 | 1 | matches |
Data and users
| What | Original | New | matches |
|---|---|---|---|
| Bookings | 77 | 77 | matches |
| Clients | 25 | 25 | matches |
| Dogs | 26 | 26 | matches |
| Waitlist | 9 | 9 | matches |
| Messages | 25 | 25 | matches |
| Users | 1 | 1 | matches |
| Password hash | not shown | same | matches |
Only invented demo data and our own test owner account were moved. The site itself was not switched to the new database.
Moved with the export
- Schema, row level security, policies30 tables, RLS on for the same 15 tables as in the original
- Rowsthe demo data came with the export, the app’s own reset function filled the tables, and the counts match the original
- Users and password hashesthe hash is identical to the original
- Grants for the API roleskept: from 30 October 2026 Supabase exposes new tables to the API only with explicit grants
Set up by hand in the new project
- Scheduled jobs (pg_cron)not moved: they live in the system schema cron and are created again
- Lovable’s own rolethe role doesn’t exist in Supabase, so its grants are skipped
- Server code with the service keynew keys go where the site is hosted, set by the owner
- Sign-in providers and secretsset by the owner in the new project