How do I connect Supabase to Lovable?

In your Lovable project, open the Supabase integration and authorise Lovable to connect to an existing Supabase project (or create a new one), then Lovable can read and write to it the same way it does with Lovable Cloud.

How do I create a database in Lovable?

Ask Lovable to set up Lovable Cloud (or connect your own Supabase project) and describe the tables you need — Lovable provisions the Postgres database and creates the tables from your description.

How do I create database tables?

Describe the table's purpose and fields in plain language to Lovable — including which fields are required, their types, and any relationships to other tables — and Lovable generates the table with appropriate row-level security policies.

How do I view my database data?

Open the Cloud tab (or ask Lovable) to browse tables, edit rows and run SQL directly inside your project — no separate Supabase login needed.

Why isn't Lovable saving data?

Most commonly this is a missing or misconfigured RLS policy blocking the insert/update, an unconnected database, or a form that never calls the backend at all.

Why is Supabase returning a 403 error?

A 403 means Row Level Security blocked the request — the current user's role doesn't match any policy allowing that read or write on that table.

What is Row Level Security (RLS)?

RLS is a Postgres feature that restricts which rows a query can see or change, enforced per-row on the database itself rather than trusted to your app's code.

Do I need RLS on my Lovable app?

Yes, for almost any app with user data, private content or logged-in users — without RLS, anyone can read or write any row via the database's public API.

How do I fix RLS errors?

Identify which operation and role is being blocked, then ask Lovable to add or correct the specific policy for that table rather than disabling RLS.

Why can users see other users' data?

Almost always a missing or too-permissive RLS policy — either RLS isn't enabled on the table, or a policy allows reading rows regardless of who owns them.

How do I safely store API keys?

Store keys as secrets in your backend (Lovable Cloud/Supabase) and call the third-party API from a server/edge function — never put keys in front-end code.

How do I use environment variables?

Use `VITE_`-prefixed variables only for non-sensitive, public values baked into the front-end build; use Secrets for anything sensitive that a server/edge function needs.

What are Supabase Edge Functions?

Edge Functions are small serverless backend functions that run outside the browser — used for anything requiring a secret key, a third-party call, or logic that shouldn't be trusted to the client.

When should I use an Edge Function?

Use one whenever your app needs a secret key, must call a third-party service, or needs logic that shouldn't be trusted to run in the user's browser.

How do I upload and store files?

Ask Lovable to add file uploads and it will wire up storage in Lovable Cloud (or your connected Supabase project), including an upload UI and access policies for the files.

How do I back up my Lovable database?

Lovable Cloud stores backups you can restore from directly in the Database screen; for extra safety, also ask Lovable to export your data periodically.

How do I migrate a database?

Describe the schema change you want in chat and let Lovable write and apply the migration — it handles new tables, columns and RLS policy updates together.

Can I move from Lovable Cloud to Supabase?

Yes — Lovable Cloud is a Supabase backend under the hood, and Lovable supports connecting your own Supabase project instead, though moving existing data across takes an export/import step.

What is Lovable Cloud?

Q: When should I use Lovable Cloud?

Use Lovable Cloud for most new projects needing a backend — it's the fastest path with no separate account; connect your own Supabase project instead if you already have one, need direct dashboard access, or must integrate with existing Supabase infrastructure.

Last checked 31 Aug 2026

Short answer

Lovable Cloud is a Supabase backend (Postgres database, authentication, storage, edge functions) that Lovable provisions and manages for your project automatically, with no separate account or dashboard needed.

What it actually is

Lovable Cloud is Supabase running behind the scenes for your project. You don't create a Supabase account or log into a separate dashboard — Lovable provisions the database, handles migrations, and exposes the results through chat and the built-in Database view.

It gives you:

A managed Postgres database
Authentication (email/password, social logins, one-time codes)
File storage (buckets for uploads)
Edge functions (server-side code for things like calling third-party APIs or sending email)
Access to Lovable AI, so your app can call AI models without you supplying your own API key

How it differs from "bring your own Supabase"

	Lovable Cloud	Your own Supabase project
Account needed	No — managed within Lovable	Yes, a separate Supabase account
Dashboard access	None — ask Lovable to make changes	Full Supabase dashboard access
Usage cost	Included in your Lovable credit balance (monthly Cloud allowance)	Billed separately by Supabase
Best for	Most projects, especially non-coders	Teams needing direct dashboard control or existing Supabase infra

See when should I use Lovable Cloud for which fits your project.

Getting started

Set up Lovable Cloud for this project and create a subscribers table for an email sign-up form.

Lovable enables Cloud, creates the table, and applies sensible defaults like row-level security — always check the policy matches what you actually want before relying on it.

What usually goes wrong

Expecting dashboard access: because there's no separate Supabase login, any change — new table, policy, secret — goes through asking Lovable, not clicking around a Supabase UI.
Not checking RLS policies: Cloud makes adding a database fast, but security policies still need to be reviewed for each table, especially ones storing user data.
Confusing Cloud usage with build credits: Cloud usage draws from a separate monthly allowance alongside your credit balance — check Lovable's pricing page for current limits rather than assuming.

What you get when Lovable Cloud is enabled

Enabling Cloud provisions a managed backend for the project and wires it into your app automatically. That gives you:

A Postgres database with tables, relationships and row level security
Authentication — email/password, magic links and social providers
File storage for uploads, images and documents
Server-side functions for logic that must not run in the browser, such as calls to paid APIs
Secrets management so API keys live on the server, never in client code
Email sending for confirmations, notifications and password resets

You do not manage servers, connection strings or deploy keys. The credentials are injected into the project for you.

When you need it

You need Cloud the moment your app has to remember something between visits: user accounts, form submissions, bookings, orders, saved documents, admin dashboards. A brochure site, landing page or portfolio does not need it — a contact form that stores enquiries does.

What to set up first

Tables — one table per real-world thing (enquiries, bookings, projects), with a column linking each row to its owner.
Row level security — on for every table, with policies that scope reads and writes to the signed-in user, plus admin-only policies where needed.
Roles — stored in their own table, never as a column on a profile, so a user cannot promote themselves.
Secrets — added through the platform, then read only in server-side code.

Cost and limits

Cloud usage is metered as part of your Lovable plan rather than billed by a separate provider, so a small app with modest traffic generally sits inside plan limits. Heavy usage — large file storage, high query volume, big email sends — is what pushes it up. Reducing unnecessary database calls is the single most effective way to keep usage low.

Checks before launch

Every table has row level security enabled and policies that a signed-out visitor cannot bypass
No API key or secret appears anywhere in client-side code
Auth flows tested end to end: register, confirm, log in, reset password, log out
Admin pages verified with a normal, non-admin account
A backup taken before you publish

Sources

Was this answer helpful?

Next step

GuideHow to Connect a Backend to Your Lovable ProjectTurn on the database, authentication and server layer, and understand what each part is actually for before you start using it.

You might also need

GuideHow to Create Your First Database TableColumn types, defaults, required fields and relationships — designed so you are not migrating data in three weeks.