Lovable and Supabase — which setup should you use?

They are the same technology

This trips people up: Lovable Cloud is Supabase, managed for you. Postgres database, row-level security, the auth service, storage buckets — identical concepts. The difference is who holds the account and how the connection is wired.

	Lovable Cloud	Your own Supabase project
Account setup	None — provisioned in one step	You create and own it
Keys and connection	Handled automatically	You paste the URL and keys
Dashboard	Managed through Lovable	Full Supabase dashboard
Billing	Part of your project	Separate Supabase bill
Best for	New builds, fastest path	Existing data, org-owned accounts

Choose Lovable Cloud when

• You are starting fresh.
• You do not want a second dashboard, second bill and a set of keys to keep straight.
• You want the AI to create tables, policies and functions without connection plumbing to break.

For most builds this is the right answer, and the failure modes are far fewer — no wrong key, no wrong project, no environment mismatch.

Bring your own Supabase when

• Real data already lives in an existing Supabase project.
• Your company requires the database under its own account and controls.
• Another system already reads and writes that database.
• You need dashboard-level features you intend to configure yourself.

Things that behave the same either way

Row-level security. Every table needs policies. Without them the table is closed or wide open. Say it out loud in each request:

Enable row-level security. Users can read and write only their own rows; admins can read all.

Grants. New tables in the public schema need explicit privileges granted for the API roles, in the same migration as the table. Miss them and queries fail with a permission error even though the policies look correct.

Roles in their own table. Never an is_admin column on a profile the user can edit. Use a separate roles table and a security-definer function to check membership — this is the standard way to avoid both privilege escalation and recursive policy errors.

Profiles, not auth tables. Keep user-facing fields in your own profiles table keyed by the user id. Do not add columns to the managed auth tables.

Migrating between them

Moving from Cloud to your own project, or the reverse, means exporting the schema and data and re-applying policies. It is a real task, not a toggle — so decide early. If the data will one day need to live under a client's own account, start there.

A safe table-creation prompt

Create an orders table: id, user_id defaulting to the signed-in user, customer_email, total_cents integer, status text defaulting to 'pending', created_at timestamp defaulting to now. Enable row-level security. A user can insert and read only their own orders. Admins can read and update all orders. Grant the API roles the privileges those policies need.

That single prompt produces the table, the security and the access grants together — which is exactly how a database change should arrive.

Testing your data rules

Create two accounts and try to read the other's rows. If it works, your policies are wrong. This ten-minute test catches the most damaging class of bug a small app can ship.