What's the difference between Lovable Cloud and Supabase?

Same engine, different ownership

Lovable Cloud is powered by Supabase behind the scenes. The difference is who holds the keys.

	Lovable Cloud	Your own Supabase
Account needed	No	Yes
Dashboard access	Through Lovable	Full Supabase dashboard
Billing	Part of Lovable credits	Separate Supabase plan
Setup effort	One toggle	Connect and configure
Portability	Managed by Lovable	Entirely yours

Choose Lovable Cloud when

• You want database, auth, storage and server functions with no extra accounts
• You are validating an idea and want speed
• You do not need direct SQL dashboard access

Choose your own Supabase when

• You already have a Supabase project or team
• You need dashboard-level control, extensions or specific compute
• Compliance requires you to own the data infrastructure directly

Switching later

It is a migration, not a toggle: schema, data, policies and environment keys all move. Decide early if you have a strong preference.

The short version

Lovable Cloud is the managed backend built into Lovable. Supabase is the underlying platform it is built on. With Cloud, the database, auth, storage, functions and secrets are provisioned and wired into your project automatically, and usage is billed as part of your Lovable plan. Bringing your own Supabase project means you create and manage that project yourself, hold the credentials, and pay Supabase directly.

	Lovable Cloud	Your own Supabase project
Setup	Automatic	You create the project and connect it
Credentials	Injected for you	You manage keys and rotation
Billing	Part of your Lovable plan	Direct with Supabase
Dashboard access	Managed inside Lovable	Full external dashboard
Best for	Most builds, fastest path	Teams with existing infrastructure or strict data-residency needs

Which to choose

Choose Cloud unless you have a concrete reason not to: it removes credential handling, keeps schema changes reviewable inside your project, and means one bill. Choose your own project when you already have a Supabase database in production, need a specific region, need access for a separate engineering team, or must meet contractual requirements about who holds the data.

Moving from Cloud to your own project

It is a migration, not a switch: export the schema, move the data, re-create the auth users, re-point the credentials, then retest every flow — sign-up, login, password reset, uploads, and every access rule. Do it before you have real users if you can.

What stays the same either way

Postgres, row level security, the same policy patterns, the same client library. Everything you learn writing tables and policies on Cloud applies directly if you later run your own project, so starting on Cloud costs you nothing in transferable knowledge.