Lovable Cloud vs Supabase: who owns the database, who holds the keys, and who gets the bill

Lovable Cloud vs Supabase is a choice about whose account holds your database. Lovable Cloud is a Supabase instance that Lovable owns: you get no service role key, no database URL, and no switch to your own project once it is on. We’d pick your own Supabase if a developer, an outside tool or a buyer will need the data.

Lovable Cloud vs Supabase: what is being compared, and for whom

Lovable Cloud is the backend Lovable switches on inside the builder, built on Supabase’s open-source foundation: database, auth, storage, edge functions and secrets in one place, run from Lovable’s Cloud view. Your own Supabase project runs the same engine in an account you control, billed and administered by you.

If you have already decided to leave Cloud, the steps are in moving off Lovable Cloud, step by step. This page is the decision before that, and it reads the same from either end: Supabase vs Lovable Cloud is one question about accounts, because the engine underneath does not change.

Cloud is the default. Lovable’s docs say the built-in backend is enabled for your workspace by default, and when a prompt needs sign-in or file storage, Lovable enables Cloud automatically or asks first, depending on a permission that ships set to Always allow. So a project can be on Cloud before anyone chose it. Supabase’s page on identifying a Lovable backend says that in this case the Supabase instance “is owned and managed by Lovable, not by your personal Supabase account.”

The other path is a project in your own Supabase account that Lovable connects to. Lovable’s Supabase integration documentation describes it as connecting “a Supabase project you own” and says to connect it when you want “your own Supabase account and billing, full access to the Supabase dashboard, or an existing Supabase project you already use.” Supabase in Lovable is therefore one of two things: the engine under Lovable Cloud, held in Lovable’s account, or a project you connect from your own.

Two kinds of founder need this comparison. One is deciding before Cloud is switched on. The other has a working app and wants to know what it already runs on, which the check near the end of this page settles.

Lovable vs Supabase, row by row: ownership, keys, bill and exit

The comparison between Lovable Cloud and your own Supabase project comes down to five differences: who owns the project, who holds the service role key and database URL, which tools can connect, who sends the bill, and whether you can switch later.

Set Lovable vs Supabase side by side on features and the columns match, since Lovable says Cloud gives you “the same database, auth, storage, and edge function capabilities” without any setup. The rows that differ are about accounts: rows 1, 3, 5, 6 and 9 below carry the five differences, and the other six give context.

Checked 20 October 2026 against each vendor’s documentation.

If your app already runs on Cloud and a developer, a customer’s security review or a buyer will soon need the database, bring it to a free audit: we talk through with you which side your app is on, who owns each account, and what the next step would cost to undo. In our Production Hardening Sprint, deliverable 2.8 moves every service the product depends on (database, hosting, payments, email, AI, domain) into an account the founder owns, with the founder as the owner role, and 7.11 keeps the application in a version-controlled repository and on a hosting account the founder controls, independent of the tool that generated it. We apply the equivalent controls for your database and framework, and the implementation follows your stack. Hosting, paid tools and API usage are paid through your accounts.

Who holds the keys: the service role key, the database URL and the SQL editor

The service role key and the database URL stay out of reach on Lovable Cloud: Supabase’s troubleshooting docs state that Cloud projects give no access to either, and external connections are not supported. On your own project both are yours, to keep server-side.

Supabase puts it in two sentences. The identify page says: “You won’t see this project in your Supabase Dashboard, and you won’t have access to service role keys or direct database URLs.” Supabase’s page on Lovable Cloud projects, answering a question about BI tools and Postgres connectors, says: “External connections are not supported when your project runs on Lovable Cloud.”

The SQL editor is where the two vendors seem to disagree, and both are right. Lovable lists a SQL editor among its Cloud tools, to “Run SQL queries and commands against your database.” Supabase’s FAQ says Cloud projects get no “direct SQL editor access through supabase.com/dashboard.” So there is an editor, it lives inside Lovable, and you reach the data on Lovable’s terms.

Three ordinary requests run into that wall. A developer you hire asks for the connection string, and Supabase’s answer for Cloud is that “connection credentials are not exposed.” A BI tool needs to read revenue straight from Postgres, and Cloud supports no external connections. An automation in n8n or Make that asks for a service role key gets the same answer: on Cloud those keys “are not accessible,” and Supabase’s advice for automation and API tools is to “create and manage your own Supabase project, then connect Lovable to it directly.” Lovable’s route on either backend is an edge function that acts as an endpoint or webhook for the tool.

On your own project the key exists and belongs to you, and Supabase’s rule for it applies in full: secret keys “provide full access to your project’s data, bypassing Row Level Security,” and you should “Never put one in a browser, a shipped application, or source control.” Supabase also says it is deprecating the anon and service_role keys by the end of 2026, and points to the publishable and secret keys instead. The pattern for keeping these keys on the server is set out in where admin keys belong in an AI-built app.

Who gets the bill: Lovable credits or a Supabase invoice

The bill for Lovable Cloud comes out of the same Lovable credit balance that pays for building the app, so once the monthly Cloud grant is used, heavy use of the live app competes with your own edits. Your own Supabase project sends its own invoice, on its own plan and limits.

Lovable’s Cloud documentation puts it in one line: “Lovable uses one credit balance for building your app, hosting it and running its built-in backend (Cloud), and AI features in deployed apps.” The usage screens show that balance as Build credits, for building and chat, and Run credits, for Cloud, AI gateway and connector usage, and Lovable’s usage docs say these “are reporting views, not separate credit balances.” Free, Pro and Business plans include a monthly Cloud grant of 20 credits, which Lovable calls a temporary offering subject to change; once it runs out, Cloud usage draws from your general credits.

At a zero balance, building stops behind a dialog, AI features in deployed apps fail with an error, and Lovable “pauses your app’s backend services, such as the database, storage, and authentication, when the monthly Cloud grant and your general credits are both gone.” The published pages keep serving and Lovable keeps the data, but you cannot access or export it until the services run again, and daily build credits cannot pay for Cloud. A busy week for the live app is also a week with fewer credits left to fix it.

On your own project, the database sits on your Supabase subscription, billed by Supabase, while Lovable credits go on building in Lovable. The credit side is broken down in how Lovable credits are charged, and plan prices on the other side in what a Supabase plan costs.

Lovable Supabase storage quota on each side

The Lovable Supabase storage quota depends on which side holds the project, and the two sides measure it differently. On Cloud, stored files and database storage are both metered as Cloud usage and paid from credits, and a fixed file storage quota is not stated in Lovable’s docs. Each upload is capped at 2 GB by default, and you can raise the limit up to 5 GB. On your own project, Supabase sets a fixed allowance per plan and bills extra storage per GB on Pro; the table has the figures.

Checked 20 October 2026. How Cloud’s storage affects a move off it is part of moving off Lovable Cloud, not of this choice.

The day you want out: what each side lets you take

The way out of Lovable Cloud is an export, not a switch: once Cloud is on it cannot be connected to your own Supabase, and the database export leaves out storage files, edge function code and secrets. Your own project can be dumped and moved like any Postgres database.

Supabase’s wording is that once Lovable Cloud is enabled, it “cannot be disconnected or switched to an external Supabase connection,” and “There is no automated way to transfer a Supabase project from Lovable Cloud to your own Supabase account.” Removing Cloud does not free the project either: it “permanently deletes your Cloud instance and cannot be undone,” so the export has to come first.

Lovable’s database export settings set the terms. The export holds the full database, structure and data, including your users’ accounts with their password hashes, so users keep their passwords if you restore it into a Supabase project. It “does not include files in storage, Edge Function code, or your project’s secrets”; the file can be at most 5 GB from a database of up to 15 GB, and you can request one export every 24 hours, only while the backend is running. A backend paused for lack of credits cannot be exported until it runs again.

Leaving the built-in backend also means rebuilding what sat around the database. Lovable’s ownership guide says “Moving the PostgreSQL database alone does not move authentication, storage, realtime, or Edge Functions,” and names managed Supabase and self-hosted Supabase as the supported destinations for a Cloud backend.

On your own project, Supabase’s backup guide describes a manual logical restore with pg_dump and psql into a project you create, the route walked through in backing up a Supabase project. The app’s code leaves by a separate route, set out in what the Lovable code export includes, and the hosting half is in running an exported app on your own hosting.

In a Q&A app, one of the 21 third-party apps we audited in June and July 2026, the code called a stored database function that none of its seven migrations defines, and nothing in the repository applied those migrations to anything, so nobody could rebuild or reason about the live database from the code. That is one app from a set we chose to audit, not a pattern we claim for Lovable or Supabase. Our take from it: on either side, the schema you can carry out is the one kept as migrations in a repository you own.

Is it better to use Lovable Cloud or Supabase?

The better choice for most apps that will have real users is your own Supabase project, because it is the reversible one. We’d keep Lovable Cloud for a prototype, a demo or an internal tool that nobody outside Lovable needs to reach.

The pick column below is our guidance; the why column comes from the vendors’ docs.

Supabase’s advice points the same way for anyone who wants to run the database themselves: “Avoid enabling Lovable Cloud if you plan to manage your Supabase project independently.” Lovable’s integration page adds that switching is not automatic, “so it’s worth deciding early which backend you want a project to use.”

The same backend choice on Bolt, Replit, v0 and Base44

Every builder with a backend has to answer whose account holds the data, and these four builders answer it in four different ways.

The rows come from Bolt’s database docs, Replit’s connection details, v0’s database docs and Base44’s app data docs. Bolt’s pages differ on one point: its database page says “There’s currently no supported way to migrate an existing Bolt database to Supabase,” while its Supabase integration page says claiming “lets you migrate an existing Bolt database to Supabase” on a Pro or Teams plan. Lovable Cloud sits on Supabase, the same backend a Bolt Pro or Teams user can claim into their own Supabase organization, yet a Cloud project gives the customer no part of the Supabase account.

How to check which backend your app runs on, and who owns it

The backend a Lovable project uses is shown in the Cloud view of the project editor, and the owner shows in whose Supabase dashboard the project appears. Three checks settle it: the Cloud view, your Supabase organization, and an ownership list for every provider.

1. 01 In the Lovable editor, open More, then Cloud: screens for Database tables and Users mean Lovable Cloud, while your Supabase project's name with some links to the Supabase dashboard means your own project. Save a screenshot of what you see.
2. 02 Sign in to the Supabase dashboard with your own account and look for the project in your organizations: listed means your account can see it, missing means it sits in an account you cannot see, such as Lovable's. Note the organization and who owns it.
3. 03 List every provider the app depends on (database, hosting, payments, email, AI, domain), the account that owns each one and who holds the owner role, then date the list.

In our sprint, deliverable 2.8 is verified this way: we produce an inventory listing each provider, the owning account, the owner role holder, and the date the previous builder’s access was removed.

Moving each of those accounts into the founder’s name is its own job, set out in moving every provider into accounts you own.

Common questions about Lovable Cloud and Supabase

Are Supabase and Lovable the same?

No. Lovable is an AI app builder that hosts your app, while Supabase is a backend platform; Lovable’s built-in backend, Lovable Cloud, utilizes Supabase’s open-source foundation, and a Cloud project’s Supabase instance is owned and managed by Lovable rather than by your Supabase account.

How do I connect Lovable to Supabase?

Connect it through Lovable’s Supabase integration, which is available on all plans: a workspace owner or admin links your Supabase organization once, then anyone with edit access can open More, then Cloud in the editor, click “Already have a Supabase project? Connect it here” and pick the project. That link appears on projects that have no backend yet, and a project already on Lovable Cloud cannot be switched to an external Supabase connection.

Is Lovable Cloud free?

Only up to a point: Lovable gives Free, Pro and Business workspaces 20 credits a month for Cloud usage, a grant it describes as temporary and subject to change, and anything beyond that is paid from the workspace’s general credits. Enterprise plans include no Cloud grant.

When should I get help choosing between Lovable Cloud and Supabase?

Before the app takes customers’ data on Cloud, or before a developer or buyer needs access to the database, because a Cloud project cannot later be switched to your own Supabase project. AxonBuild runs a free audit where we talk through with you which side fits your app and what moving later would involve.