Lovable projects store data in Lovable Cloud by default, a managed backend built on Supabase's open-source foundation that is not visible in your own Supabase dashboard. You create tables through chat prompts, manage everything from the Cloud tab, and can connect your own external Supabase project or another database through an Edge Function proxy if you need more control than Lovable Cloud provides.
| Fact | Value |
|---|---|
| Tool | Lovable |
| Difficulty | Beginner |
| Time required | ~15 min to understand, ongoing as you build |
| Compatibility | Lovable Cloud: all plans, with a monthly Cloud credit grant on Free and usage-based billing from the unified credit balance on paid plans. |
| Last updated | September 2026 |
Why Lovable's database setup confuses people who already know Supabase
The confusion around 'Lovable database' almost always comes down to one fact people miss: Lovable Cloud is managed Supabase, but it is not your Supabase. Lovable Cloud is managed Supabase and is not visible in your own Supabase dashboard — it is a separate, Lovable-provisioned instance that you only ever interact with through the Cloud tab inside the editor. Someone who already has a Supabase account will naturally go looking for the project there and find nothing, because it does not exist on that side. The other recurring issue is Row Level Security. Because Lovable creates tables from a chat prompt rather than a manual SQL editor, it is easy to assume access control is handled automatically. Sometimes it is, especially for straightforward auth-linked tables, but it is not guaranteed for every table, and a table without RLS is fully readable and writable by anyone with the public anon key. This is the exact failure mode behind widely reported 'exposed Supabase data' incidents in AI-built apps — not a platform breach, but a missing policy on a specific table.
- Lovable Cloud is a Lovable-managed Supabase instance, not a project visible in your own Supabase account
- Tables are created from chat prompts, which can silently skip explicit Row Level Security if the prompt does not ask for it
- External databases must go through an Edge Function proxy, since raw connection strings are never safe to expose to the frontend
- Credits, not a separate database bill, cover Lovable Cloud usage, which surprises teams used to a dedicated Supabase invoice
Before you start
- A Lovable project with Lovable Cloud enabled, or your own Supabase project ready to connect
- A clear idea of your main data entities and who should be able to read or write each one
- Comfort describing schema changes in plain language through chat prompts
How to fix it
Understand what Lovable Cloud actually is
Confusing Lovable Cloud with your own Supabase account leads to hours of searching for a dashboard that does not exist
Lovable Cloud is a managed backend built on Supabase's open-source foundation, provisioned automatically the moment a project needs a database, authentication, storage, or edge functions. Important disclaimer: Lovable Cloud is managed Supabase and is not visible in your own Supabase dashboard. There is no separate supabase.com login, no project you can find in your Supabase account, and no way to browse it outside the Lovable editor's Cloud tab. If you already have a Supabase account, do not go looking for the project there — it is a different, Lovable-managed instance.
Expected result: You know that Lovable Cloud and 'your own Supabase project' are two separate things, even though they share the same underlying technology.
Create tables through chat prompts, not a manual schema editor
This is the core workflow difference from a traditional Supabase setup, where you would normally use the SQL editor or Table Editor directly
Describe the data you need in plain language: 'add a projects table with a title, description, owner, and created date, linked to the logged-in user.' Lovable writes and applies the migration, generates the table with appropriate columns and types, and typically wires up basic Row Level Security for user-owned data automatically. Be specific about relationships (which table owns which) and about who should be able to read or write each table, since vague prompts produce vague — or missing — access rules.
Expected result: New tables appear, matching your description, visible under Cloud then Database in the editor.
Verify Row Level Security explicitly for every table
A table without RLS enabled is readable and writable by anyone holding the public anon key — this is the single most common security gap in AI-built apps
After creating any table, open the Cloud tab, go to Database, and check that RLS is enabled and that policies match your intent (for example, 'users can only see their own rows'). If you are unsure, explicitly prompt Lovable: 'review RLS policies on the new table and restrict access so users can only read and write their own rows.' Do not assume RLS was set up correctly just because auth exists elsewhere in the project — each table needs its own explicit policy.
Expected result: Every table shows RLS enabled with policies that match your actual access requirements, not the default permissive state.
View and manage your data in the Cloud tab
You need a way to inspect real rows, not just the schema, especially while debugging
Open the Cloud tab and select Database. This gives a table browser similar to a spreadsheet: you can view rows, filter, and in most cases edit data directly, functioning like Supabase's own Table Editor but accessed entirely inside Lovable. Use this to confirm that data created through your app's forms actually lands where you expect, and to manually seed or correct data during development.
Expected result: You can see and adjust real data rows without leaving the Lovable editor.
Decide when to move beyond Lovable Cloud
Lovable Cloud is convenient but ties your database usage to the same credit balance as everything else, and some teams need dashboard-level control or an existing database
If you already run production data in your own Supabase project, or need direct SQL access, backups on your own schedule, or dashboard-level admin control, connect your own Supabase project instead: add its URL and keys as Secrets and prompt Lovable to use that connection for new features. For databases outside the Supabase/Postgres world entirely (MongoDB, a legacy MySQL instance, an internal API), route access through an Edge Function that holds the credentials as Secrets, since the frontend should never hold a raw database connection string. For projects with real production data, non-trivial migrations, or a mix of Lovable Cloud and external systems, RapidDev's engineers handle exactly this kind of database architecture work as part of standard $13K-$25K engagements.
Expected result: You have a deliberate database architecture — Lovable Cloud, your own Supabase, or a proxied external database — rather than an accidental default.
Best practices to prevent this
- Always verify Row Level Security explicitly for every new table — do not assume it was handled automatically
- Remember Lovable Cloud is managed Supabase and is not visible in your own Supabase dashboard, so stop looking for it there
- Use the Cloud tab's Database view regularly to confirm data actually looks the way your app's forms should be producing
- Connect your own Supabase project instead of Lovable Cloud if you need direct SQL access or dashboard-level admin control
- Route any non-Supabase database (MongoDB, MySQL, an internal API) through an Edge Function, never directly from the frontend
- Be specific about relationships and access rules in prompts — 'add a table' with no context produces a table with no meaningful policies
Still stuck?
Copy one of these prompts to get a personalized, step-by-step explanation.
I'm designing the database for a Lovable.dev project and want a second opinion before I build it. Here is the app: - What it does: [describe the app] - Main entities: [users, projects, orders, etc.] - Who should see what: [describe access rules per entity] - Using Lovable Cloud or my own Supabase project: [which one] Please help me: 1. Sketch a normalized table structure with relationships 2. Write out the Row Level Security policy I should ask Lovable to apply to each table 3. Flag any table that clearly needs restricted access but is easy to forget (e.g. billing data, admin flags) 4. Suggest what should live in an Edge Function instead of being queried directly from the frontend
Review every table in this project's database and list which ones have Row Level Security enabled and which do not. For any table without RLS, propose a policy so users can only read and write rows they own, and apply it after I confirm.
Frequently asked questions
Where does a Lovable project's database actually live?
By default, in Lovable Cloud, a managed backend built on Supabase's open-source foundation. This is not the same as having your own Supabase project — Lovable Cloud is not visible in your own Supabase dashboard, and there is no separate Supabase login for it. Everything is managed from the Cloud tab inside the Lovable editor.
Is Lovable's database the same as Supabase?
It runs on Supabase's technology (PostgreSQL, Auth, Storage, Edge Functions), but it is Lovable's managed instance of it, not a project you can log into at supabase.com. If you need direct Supabase dashboard access, connect your own separate Supabase project instead of using Lovable Cloud.
How do I create database tables in Lovable?
Describe what you need in a normal chat prompt — for example, 'add a table for user profiles with a display name and avatar URL' — and Lovable generates the schema and the migration for you. You can review and inspect the resulting tables afterward in the Cloud tab under Database.
Does Lovable automatically set up Row Level Security (RLS)?
It generates RLS policies as part of building auth-related features, but you should always ask it to review or add RLS explicitly for any new table, and verify the policies in the Cloud tab. Missing RLS is the single most common security issue in Lovable-built apps, since a table without RLS is readable and writable by anyone with the public key.
Can I connect my own Supabase project instead of using Lovable Cloud?
Yes. This is common when you already have data elsewhere, need dashboard-level control, or want to avoid Lovable Cloud's usage-based credit billing. You provide your own Supabase URL and keys as Secrets, and prompt Lovable to use that connection instead of provisioning a new Lovable Cloud database.
Can I connect a completely different database, like MongoDB or MySQL?
Yes, but not directly from the frontend. External databases are connected through an Edge Function acting as a secure proxy, since exposing database credentials or connection strings to the browser is not safe. The Edge Function holds the credentials as Secrets and the frontend only talks to the Edge Function.
How do I view or edit the actual data, not just the schema?
Open the Cloud tab, then Database, inside the Lovable editor. You get a table browser similar to a spreadsheet where you can view rows, and depending on the setup, edit data directly. This is the equivalent of Supabase's Table Editor, just accessed through Lovable's own interface.
What if I can't fix this myself?
Database design mistakes are expensive to unwind once an app has real users and data. RapidDev's engineers regularly review and fix Lovable Cloud schemas, RLS policies, and migrations to external databases as part of standard $13K-$25K project engagements.
Talk to an Expert
Our team has built 1,000+ apps. Get personalized help with your issue.
Book a free consultation