Migrating from Lovable Cloud to your own database

Why people leave Lovable Cloud

• No direct database access — no pg_dump, no credentials, no second environment for staging.
• Costs that move with usage in ways that are hard to predict once real users show up ("cloud credits" consumed by a database that is just sitting there).
• Buyers and institutions that will not sign off on data they cannot see or back up.
• The Test/Live environments beta is being retired (October 2026), so the one database is also the only database.

Everything that has to move

A migration is not "copy the front end." The list I work through for every Lovable Cloud app:

• Schema and data — every table, index, constraint, view and RLS policy, then the rows.
• Auth users — including password hashes and OAuth identities, so nobody has to reset a password or re-link Google.
• Storage — buckets, files and the policies on them.
• Edge functions and their secrets — API keys, webhook signing secrets, service credentials.
• Scheduled jobs (cron), database triggers and any realtime subscriptions.
• Third-party webhooks that point at the old backend: Stripe, Twilio, Resend, calendar providers.
• Environment variables in the front end, custom domain and DNS, and a rollback plan for the cut-over window.

How I run the migration

• Inventory first: I map every table, function, secret, job and webhook and write down what "working" means for each feature.
• Build the new Supabase (or Postgres) project from the repo's migrations, then export and load the data using Lovable's data-export path plus verification queries on both sides.
• Move auth with hashes intact, re-point storage and functions, rotate secrets, and re-register webhooks.
• Run the app against the new backend on a staging URL and click through every feature. Only then switch production, with the old backend kept warm for rollback.
• Hand you the keys: your Supabase organisation, your GitHub repo, your hosting account. I keep access only as long as you want me to.

Supabase or plain Postgres?

If your app uses Supabase auth, storage or edge functions — most Lovable apps do — your own Supabase project is the shortest, safest move and keeps Lovable usable afterwards. If you need a specific cloud (a buyer insists on AWS or Google Cloud), or the app has outgrown edge functions, I move the database to managed Postgres and give the app a small server of its own. The findings report tells you which one fits and what each costs to run per month.

Questions