Lovable and Supabase: connect, add auth and lock down your data

Do you need Supabase to build with Lovable?

No. According to Lovable's Supabase documentation, Lovable's built-in backend is enabled by default and covers a database, authentication, storage and edge functions with no separate account. Lovable describes it as using Supabase's open-source foundation. Most projects never need to connect their own Supabase project.

Connect your own project when you want to own the backend: your Supabase account and billing, full access to the Supabase dashboard, or an existing Supabase project you already use. The choice matters early, because there is no automatic migration between the two in either direction.

For what the built-in backend costs in credits, see Lovable pricing. If you want the broader picture first, start with what Lovable is.

How do you connect Supabase to Lovable?

Connecting is two separate actions, often done by different people. A workspace owner or admin links a Supabase organization once. After that, anyone with edit access to a project can connect it to a Supabase project in that organization, without needing their own Supabase account.

1. Create a Supabase account and project, or have an organization where you can create one. The free tier is enough to start.
2. Link the organization. In Lovable, open Connectors from the dashboard sidebar, select Supabase and choose Connect Supabase. A Supabase window opens where you sign in and authorize Lovable for the organization you pick.
3. Open the project connect dialog. In the editor, go to Settings, then General, then External Supabase, and click Connect. The option appears on projects that do not have a backend yet.
4. Choose a Supabase project. Click Connect next to the project you want. If you have not created one, Create Project opens the Supabase dashboard.
5. Verify. Open More, then Supabase. You should see the project name and its status, with links to the Supabase dashboard.

You can also pick a Supabase project when you create a new Lovable project: click the plus in the prompt box on the dashboard, open Databases and choose one under the Supabase heading.

Lovable can also create the Supabase project for you, inside your own organization, when the built-in backend is disabled for your workspace and your project has no backend yet. You pick the organization and region on an approval card. The region cannot be changed afterwards, and Supabase bills the new project to your organization.

How does Lovable build and change your database?

You describe the data in plain language and Lovable designs the tables, columns and relationships. Schema changes run as reviewed migrations: Lovable writes the SQL, shows it to you, and asks for approval in the project chat before running it. After you approve, it executes the migration on your Supabase project, saves the file under supabase/migrations/ in your project's code, and regenerates the TypeScript types your app uses. It also asks before inserting or changing data. The old routine of pasting SQL into the Supabase editor is no longer needed.

The quality of the schema depends on the quality of your description. Say what you store, who owns each row and who may read it. That last part decides your security later.

Add a database for [what the app stores].

Tables:
- [table name]: [fields and types]. Each row belongs to one signed-in user.
- [table name]: [fields and types]. [Who can read it: only the owner / any signed-in user / anyone]

Rules:
- Users can only see, edit and delete their own rows.
- Show me the migration before you run it, and list the row-level security policies it creates.
- Do not add any table I did not list.

You can always open the Supabase dashboard to check the result. The Table Editor shows rows in a spreadsheet view, and the SQL Editor runs your own queries. For a project that needs per-user data, such as Subscription graveyard posted on the board, this ownership rule is the whole security model.

How do you add login with Lovable and Supabase?

Ask for it in the chat and Lovable wires the pages to Supabase Auth. Users who sign up through your app appear under Authentication in the Supabase dashboard, where you can also add test users.

Add email and password sign up and login with Supabase Auth.

- A signed-out visitor sees only the landing page and the login form.
- After login, send the user to /dashboard.
- Add a sign out button in the header.
- Redirect any signed-out visit to /dashboard back to the login page.

• Auth settings live in Supabase, not Lovable. On your own Supabase project, enable providers such as Google or GitHub in the Supabase dashboard under Authentication and supply the OAuth credentials, then ask Lovable to add the matching sign-in button.
• Turn off email confirmation while testing, in the dashboard's Authentication settings, so test accounts can sign in at once. Lovable's docs say to re-enable it before you launch to real users.
• Managed Google sign-in and SAML SSO from the chat work on the built-in backend only. With your own project, configure them in Supabase.

What is row-level security and why does it matter here?

Row-level security (RLS) is a Postgres feature that decides, row by row, who can read or change data. Your Lovable app talks to Supabase from the browser, so the database itself has to refuse requests it should not answer. Without RLS, the browser is the only thing standing between a visitor and your tables, and visitors can bypass the browser.

Lovable states the risk plainly in its docs: before going live, make sure every table has policies that restrict who can read and write each row, and verify them in the Supabase dashboard. It also says missing policies are the most common way app data gets exposed. Supabase's row-level security guide is blunter: a table in an exposed schema without RLS is readable and writable by any role with a grant on it.

Lovable runs automated security checks and flags issues after schema changes. Its security documentation says the Quick scan runs automatically each time you publish and looks at database access, for example tables without per-record access control and rules that let everyone through. Lovable also says these tools support secure development but do not replace a thorough security review.

Here is the standard pattern for a table where each row belongs to one signed-in user. It follows the shape Supabase documents: turn RLS on, take back the broad default grants, grant only what signed-in users need, then write one policy per action.

create table public.subscriptions (
  id uuid primary key default gen_random_uuid(),
  user_id uuid not null default auth.uid() references auth.users (id) on delete cascade,
  name text not null,
  monthly_cost_cents integer not null check (monthly_cost_cents >= 0)
);

alter table public.subscriptions enable row level security;

revoke all on table public.subscriptions from anon, authenticated;
grant select, insert, update, delete on table public.subscriptions to authenticated;

create policy "Read own rows" on public.subscriptions
  for select to authenticated
  using ((select auth.uid()) = user_id);

create policy "Insert own rows" on public.subscriptions
  for insert to authenticated
  with check ((select auth.uid()) = user_id);

create policy "Update own rows" on public.subscriptions
  for update to authenticated
  using ((select auth.uid()) = user_id)
  with check ((select auth.uid()) = user_id);

create policy "Delete own rows" on public.subscriptions
  for delete to authenticated
  using ((select auth.uid()) = user_id);

You do not have to write this by hand. Ask Lovable to produce it, then read what it ran. Supabase notes two traps worth remembering. A policy written as to anon using (true) lets every signed-out visitor read every row the role can reach, so use it only for data that is meant to be public. And views bypass RLS by default, so a view over a protected table can hand out rows its policies were meant to withhold.

What should you check before you publish?

1. Every table has RLS on. In the Supabase dashboard, open each table in the Table Editor and confirm RLS is enabled. Lovable's scan flags tables without it, but look yourself.
2. Each policy matches a sentence you can say out loud, such as users can read and change only their own notes. If you cannot say it, you cannot test it.
3. Test with two accounts. Create a row as user A, sign in as user B and confirm B cannot see, edit or delete it, in the app and in the Supabase table view.
4. Test signed out. Open the app in a private window and confirm that pages and data meant for users are not reachable.
5. Secrets are in Supabase, not in code. Lovable prompts for API keys through a secure input and stores them in your Supabase project, where edge functions read them. They should never appear in the repository. The service-role key bypasses RLS, so it belongs only in server-side functions.
6. Email confirmation is back on if you turned it off for testing.
7. Run the security scan from the project Security view, fix what it reports, and read the findings rather than dismissing them.

For the wider problem of shipping AI-built apps safely, see the guide to vibe coding security.

What about edge functions, secrets and file storage?

Edge functions are small serverless functions that run on Supabase for work that cannot or should not run in the browser: calling an AI model, sending email, handling payment webhooks, scheduled jobs, and calls to APIs that need secret keys. You describe the behavior and Lovable writes the function, deploys it to your Supabase project, and updates the app to call it. When a function fails, Lovable reads its logs and surfaces the error in the chat; you can also read them yourself in the dashboard under Edge Functions.

For uploads, ask for the feature and Lovable creates the storage buckets, asking for approval before it creates or changes them. Bucket permissions deserve the same scrutiny as table policies. On Supabase's free tier, individual files are limited to 50 MB, and the other limits follow your Supabase plan.

What are the limits and common errors?

Each Lovable project connects to one Supabase project at a time, and Supabase usage limits follow your Supabase plan. Some Lovable features only work on the built-in backend. If you rely on them, think twice before connecting your own project.

• The Database, Users, Storage, Secrets, Jobs, Usage and Logs views in the More panel. Use the Supabase dashboard instead.
• Daily backups, pausing and instance resizing from inside Lovable.
• Authentication emails sent from your own domain.
• Enabling social providers and changing auth settings from the chat, including managed Google sign-in and SAML SSO.
• Signed-in browser testing and sensitive data scanning.

Disconnecting stops Lovable from deploying edge functions and reading your schema. It does not change your code or delete anything in Supabase, and you can reconnect later.

What is a good first project for this setup?

Pick something with one table, one owner per row and a login. A habit tracker, a reading list or a simple expense log all fit, and they force you to get RLS right on a small surface. Browse the finance ideas on the board or the full idea list for something that needs per-user data, and use its generated build prompt as the brief for your first Lovable message.