Lovable Cloud vs your own Supabase: where your data actually lives

What it actually is

Lovable Cloud is Lovable’s built-in backend. When your app needs a database, user accounts, or file storage, Lovable can provision all of it inside your project, with usage billed through your Lovable plan as run credits. Under the hood it runs on Supabase’s open-source stack, and that is exactly where the confusion starts: it uses Supabase technology, but the instance belongs to Lovable’s account. Supabase’s own docs spell it out: a Lovable Cloud backend “is provisioned and managed entirely by Lovable,” it never appears in your Supabase dashboard, and you get no service role keys or direct database URLs.

Connecting your own Supabase project is the other setup. You create the project in your own Supabase account, link your Supabase organization to your Lovable workspace, and Lovable builds against it. Same technology underneath, but your name is on the account.

Think hotel room versus your own apartment. In the hotel (Cloud), the bed is made and the electricity works on day one, but you sign no lease and the utility room stays locked. In your apartment (your own Supabase), you hold every key and can bring in any electrician you like, and you also handle the boring parts yourself.

	Lovable Cloud	Your own Supabase
Shows in your Supabase dashboard	No	Yes
Service role keys, direct database URL	No	Yes
Billing	Lovable run credits	Your Supabase plan
Managed backups, in-editor backend views	Yes	No

Why your AI just did this

The first time you ask Lovable for a feature that has to remember something (“add login”, “save the user’s entries”), it needs a backend. Cloud is the default because Lovable can provision it on the spot, without you creating an account anywhere else. So it enables Cloud, writes the tables, and starts mentioning migrations and policies you never asked about.

If you connected your own Supabase instead, Lovable still designs the schema from your plain-language description, but schema changes run as reviewed migrations: it shows you the SQL and waits for your approval before anything touches your database. Auth providers get configured in your Supabase dashboard, and secrets are stored in your Supabase project rather than in your app’s code.

When you’ll run into it

The classic moment: you sign in at supabase.com expecting to find your app’s database, and the dashboard is empty. Nothing is broken and nothing was stolen. Your project is on Lovable Cloud, so the underlying Supabase instance sits in Lovable’s account, not yours.

To confirm which setup you have, click the Cloud icon in the top bar of the Lovable editor. On Cloud, you get in-editor screens for managing your tables and users. On a connected Supabase project, you see the Supabase icon, your project’s name, and links that go straight to the Supabase dashboard.

You will also meet it on the bill, since Cloud usage is metered as run credits with monthly Cloud grants on the Free, Pro, and Business plans. And at connection time: the flow lives under More → Cloud, behind a link labeled “Already have a Supabase project? Connect it here.” Linking the Supabase organization takes a workspace owner or admin; connecting a specific project only needs edit access.

The hardest encounter is on the way out. There is no automatic migration between Cloud and an external Supabase project, in either direction. Leaving Cloud means exporting your database and storage files, connecting a project you own, and re-applying the schema there. The “Hotel California” jokes on Reddit overstate it, because you can check out and take your data with you, but the move is manual.

What to check

• Open the Cloud icon in the editor’s top bar and confirm which backend your project uses before assuming anything about ownership
• Decide early: if you want the database in your own Supabase account, connect it before you pile up real data, since there is no automatic migration later
• Weigh the tradeoff honestly: an external Supabase costs you Lovable’s managed backups and in-editor backend views, plus other Cloud-only features like built-in payments
• Read the SQL of every migration Lovable proposes on a connected project before approving it, especially anything touching row-level security policies
• Export your database and download your storage files before removing Cloud from a project; that export is your copy of everything

Say it like a dev

Instead of: “Lovable is holding my database hostage” Say: “My project runs on Lovable Cloud, so the Supabase instance is managed by Lovable. Help me export the database and rebuild the schema on a Supabase project I own.”

Instead of: “I can’t find my app anywhere in Supabase” Say: “Is this project on Lovable Cloud or on a connected Supabase? If the Cloud view shows no Supabase project name or dashboard link, it’s Cloud.”

Instead of: “just move my backend into my Supabase account” Say: “There’s no automatic migration from Cloud to an external Supabase, so plan a manual move: export the data, connect my Supabase project, and re-apply the schema as reviewed migrations.”