Lovable PromptsLovable Prompts
    Updated Cloud and Supabase docs re-read 23 Oct 202630 tested policies in the kits

    Lovable and Supabase: the built-in backend, your own project, and RLS that holds

    Lovable runs on Supabase twice over. The built-in backend (Lovable Cloud) uses Supabase's open-source foundation and is on by default, billed in Lovable credits. Or you connect a Supabase project you own and Lovable builds against it, billed by Supabase. The choice is hard to undo: moving from your own Supabase to the built-in backend is not supported, and the other direction is an export and restore. Either way, Lovable's docs name the main risk: missing row-level security policies are “the most common way app data gets exposed”.

    By Marco Kohns · Docs read 23 October 2026; SaaS run 2026-09-26

    Onby default

    The built-in backend is enabled for every workspace and turns on when a feature needs it.

    1Supabase project

    Each Lovable project connects to one at a time; two projects sharing one overwrite each other's secrets.

    10.4credits

    My SaaS foundation on the built-in backend: 4 questions, sign-up, workspaces, roles in the database.

    The choice

    Should you use Lovable Cloud or your own Supabase project?

    The built-in backend for one bill and one console; your own Supabase when you need its dashboard, its billing or a database that outlives the builder.

    Lovable's built-in backend compared with a connected Supabase project, per Lovable's docs read 23 October 2026
    Built-in backend (Cloud)Your own Supabase project
    SetupOn by default; Lovable enables it when a feature needs it, or asks firstConnect a project you own; available on all plans
    BillingLovable credits (Run credits)Supabase bills your organisation
    Database changesSQL migrations; breaking changes never applied by defaultReviewed migrations: Lovable shows the SQL and asks before running it
    Social login, auth settingsConfigured from the Lovable chatConfigured in the Supabase dashboard
    Switching laterTo your own Supabase: export, restore, then auth, secrets and storage againTo the built-in backend: not supported

    Sources: Built-in backend, Supabase integration, moving a backend, read 23 October 2026. Since 20 October 2026 Lovable can also create a Supabase project from the chat, in workspaces where the built-in backend is disabled; the region cannot be changed afterwards.

    The built-in backend

    What does Lovable Cloud give an app?

    A database with live updates, user authentication, storage and functions, with the backend managed and billed inside Lovable.

    Data

    Database

    Tables you can browse and edit under More › Database, with the SQL editor, scheduled jobs, backups and access policies.

    People

    Users and sign-in

    Email and password, social logins and SSO configured from the chat, which works on the built-in backend only.

    Files

    Storage

    Buckets for uploads, with the same per-row policies deciding who reads what.

    Logic

    Functions

    Server functions for secrets, webhooks and anything that must not run in the browser.

    On my SaaS run (2026-09-26) the prompt asked for sign-up, workspaces and invites; Lovable asked 4 questions, enabled the built-in backend, built the flow, signed in as a second test user to try an invite, and reported roles checked in the database on every read and write. The whole run cost 10.4 credits. The full run is on the SaaS MVP prompt page.

    Lovable asking to run a command that signs the app preview in as an invited teammate to test joining, with Skip and Allow buttons, beside a preview of the generated landing page
    Lovable asking to sign in as a second test user to check the invite flow, during the SaaS run on 26 September 2026.

    Row-level security

    Where does row-level security break in a Lovable app?

    Where a table has no policy, where a policy lets everyone through, and where the policy exists but does not match what the app means.

    Holds

    Policies that deny

    • Every table has row-level security, deny by default
    • Roles in their own table, read by the policy
    • The owner id comes from the session, never from the client
    • A query as a second account returns zero rows

    Breaks

    The common gaps

    • A table created in a later prompt without a policy
    • using (true): the table is covered and denies nothing
    • An update policy without with check, so a row changes owner
    • A security definer function that reads around every policy

    Lovable flags missing coverage: on a connected Supabase project it runs automated checks on RLS coverage after schema changes, and the Security view's Quick scan reviews access rules at every publish. Coverage is half the answer. Its own docs tell you to verify the policies yourself, and the only proof is a query run as someone who should be denied. The security guide has the CVE that shows what happens when that step is skipped.

    Tested schemas

    What do four tested Lovable schemas look like?

    The four build kits ship a Supabase schema and a verify.sql that runs as the wrong user. Counts parsed from the files.

    Tables, row-level security policies and verification checks in the four build kits, with the trap each prevents
    KitTablesPoliciesChecksThe trap it prevents
    SaaS Starter4126a member promoting themselves to owner
    Landing Page with Email Capture117a public form that exposes the whole list
    Internal Admin Dashboard257an aggregate function that leaks the event log
    Lightweight CRM3126a record reassigned to someone else

    Leaving

    How do you take the database with you if you leave Lovable?

    Plan it before the first table exists: the backend you start on is the one you keep unless you export.

    1. 01Simplest exit

      Own Supabase from day one

      The database was always yours; the migrations Lovable ran are saved in the code under supabase/migrations/.
    2. 02Several steps

      Built-in backend, then export

      Export the database and restore it into a Supabase project, then move storage files, auth, secrets and connected services yourself.
    3. 03GitHub

      Keep the code too

      Git sync creates a new repository and syncs one branch; the code and the migration files go with it.

    Steps from Lovable docs: database backups and moving a backend, read 23 October 2026. Deleting the built-in backend permanently deletes the database, its backups, user accounts and files.

    Schemas with the proof included

    Four free build kits with tested row-level security and the queries that prove it.

    Disclosure: if you create a Lovable account through links on this page, we may earn a commission. It costs you nothing and does not change what we recommend. Create a free Lovable account

    Frequently asked

    Does Lovable use Supabase?

    Yes. The built-in backend, also called Lovable Cloud, uses Supabase's open-source foundation and is on by default, billed in Lovable credits. Or you connect a Supabase project you own, available on all plans and billed by Supabase.

    Can I switch a Lovable project from Cloud to my own Supabase?

    Not in one step. Per Lovable's docs you export the database, restore it into your Supabase project, then move storage files, code, authentication, secrets and external services. The other direction, from your own Supabase to the built-in backend, is not supported.

    Can two Lovable projects share one Supabase project?

    They can connect, but Lovable warns that projects sharing one Supabase project overwrite each other's secrets, including the LOVABLE_API_KEY, so features using that key stop working. Each Lovable project connects to one Supabase project at a time.

    Does Lovable change my Supabase database without asking?

    On a connected Supabase project, schema changes run as reviewed migrations: Lovable shows the SQL and asks for approval before running it, and also asks before inserting or changing data. Reading data to debug changes nothing.

    Does Lovable check my row-level security?

    It checks coverage: automated checks after schema changes on a connected project, and the Quick scan at every publish. Its docs also tell you to verify the policies yourself. A query run as a second account, expecting zero rows, is the check that proves a policy denies.

    Where do social logins get configured?

    On the built-in backend, from the Lovable chat. On your own Supabase project, in the Supabase dashboard's Authentication settings, after which you prompt Lovable to add the sign-in button.

    What we did not publish

    • A run on a connected Supabase project. My runs used the built-in backend.
    • Supabase's own prices, which Supabase sets and bills.
    • A credit figure for running the built-in backend over a month; Run credits depend on the app's traffic and I have no production app on it to measure.

    Sources

    1. Lovable docs: Built-in backend, read 23 October 2026
    2. Lovable docs: Supabase integration, read 23 October 2026
    3. Lovable docs: Database backups, read 23 October 2026
    4. My SaaS run, 2026-09-26; the kits' own SQL files

    Written by

    Marco Kohns

    Marco Kohns

    Founder of ProtoBites - Venture Growth Studio

    Growth PM at a Silicon Valley scale-up (a16z and General Catalyst backed), ex-Techstars where he consulted 13 early-stage startups, Reforge-trained. Every prompt on this site comes out of shipping ProtoBites' own portfolio products.

    WebsiteLinkedInX