Lovable Cloud is a Supabase instance that Lovable owns and manages. It never appears in your Supabase Dashboard, it hands out no service role key and no database URL, and once it is enabled it cannot be switched to your own Supabase project. Your own Supabase project keeps all three.
Both options run the same database engine, so the feature comparisons that fill this search result are mostly comparing the same Postgres to itself. The choice is about whose account the database sits in, and that decides three things: who holds the keys, who gets the bill, and what you can still do the day you want out. This page answers those three in that order.
I read this from Lovable’s and Supabase’s published documentation on 17 August 2026, from outside any paid account. Nothing here comes from running the product, and there are no screenshots because there was no account to screenshot.
What is Lovable Cloud, and is it Supabase?
Lovable Cloud is Supabase, and both vendors say so in print. It is the backend Lovable switches on for you: database, authentication, storage, edge functions and an AI gateway, with no separate signup. Underneath sits a Supabase instance that Lovable provisioned, on Lovable’s footprint rather than yours.
Supabase confirmed it in the launch post it published on 29 September 2025: “Every project created in Lovable Cloud is powered by Supabase behind the scenes.” Lovable’s own Cloud documentation says the same thing from its side, describing the built-in backend as running on Supabase’s open-source stack so you get a working database, auth and storage without setting Supabase up separately. That is the common ground, and the third-party comparisons on this query repeat it.
What the ranking comparisons stop short of is where the instance lives. On 17 August 2026 the Cloud documentation lists twelve tools inside Lovable: AI, Emails, Database, Users, Storage, Secrets, Jobs, Edge functions, SQL editor, Logs, Usage and Advanced settings. You reach all of them by opening the More tab in the project toolbar and selecting Cloud. Every one of those screens is a Lovable screen. None of them is supabase.com.
The other half of the fork is the older path: you create a Supabase project in your own Supabase account and connect Lovable to it. Lovable’s Supabase integration documentation, read 17 August 2026, describes that as connecting a project you own and using it as the app’s backend, and says Cloud is enabled by default so most projects never open a Supabase account at all.
So the honest one-line answer to “what is Lovable Cloud” is that it is Supabase with the account taken out of your hands. Everything below is what that costs and what it buys.
Lovable Cloud or your own Supabase: what changes in each row
The two published comparisons that rank for this query both work as feature tables, and both feature tables come out roughly even, because the features really are close. till-freitag.com, a consultancy, published one on 4 March 2026 under the byline Malte Lensch; read again on 17 August 2026, it still cites no page of either vendor’s documentation, only the Supabase homepage. training.blackbadger.biz, a paid membership site, holds the other. Neither is linked here, because both sell services into the same market this site does.
The table below is ordered differently. Feature parity sits at the bottom of it, and the rows run in the order the difference actually reaches you.
| What changes | Lovable Cloud | Your own Supabase project | Source, read 17 August 2026 |
|---|---|---|---|
| Who owns the Supabase project | Lovable | You | Supabase, identify-backend doc |
| Appears in your Supabase Dashboard | No | Yes | Supabase, identify-backend doc |
| Service role key and database URL | Not available | Yours | Supabase, both troubleshooting docs |
| SQL editor | Inside Lovable, listed as a Cloud tool | In the Supabase dashboard | Lovable Cloud docs; Supabase, cant-access doc |
| External tools (BI, Postgres clients, n8n, Make) | Not supported | Supported, using your own credentials | Supabase, cant-access doc |
| Who gets the bill | Credits in your Lovable workspace | Your Supabase subscription, billed by Supabase | Lovable Supabase-integration docs |
| When the balance hits zero | Building stops and backend services pause; the published site keeps serving | Supabase bills Supabase; the database is not tied to a builder balance | Lovable credits-and-usage docs; integration docs |
| Region | Chosen when Cloud switches on, then fixed | Chosen by you when you create the project | Lovable Cloud docs |
| Switching to the other option | Not possible once Cloud is on | Not applicable | Supabase, cant-access doc |
| Backups, instance size, pausing | Managed by Lovable | Managed by you in Supabase | Lovable Supabase-integration docs |
| Getting the data out | Export from Cloud, then rebuild the schema elsewhere | Standard Postgres dump from a project you administer | Lovable Cloud docs |
Two rows need a note. The region row is about where the database sits, not where the site sits: hosting the frontend on Vercel while Cloud stays put is a different decision and it does not move the backend. And the SQL editor row is not a typo. Both vendors are telling the truth, which is the subject of the next section.
Who holds the keys on Lovable Cloud
Supabase’s own troubleshooting pages are the only place either vendor states this plainly, and they state it in four separate sentences.
On ownership, the page for identifying which backend a Lovable project uses says: “Your Supabase instance in this case is owned and managed by Lovable, not by your personal Supabase account.” The same paragraph continues: “You won’t see this project in your Supabase Dashboard, and you won’t have access to service role keys or direct database URLs.”
On reversibility, the page for people who cannot find their Supabase project says: “Once Lovable Cloud is enabled for a project, it cannot be disconnected or switched to an external Supabase connection.”
On integration, the same page says: “External connections are not supported when your project runs on Lovable Cloud.” Its FAQ adds that service role and API keys are not accessible on a Cloud-managed project, and that the route to external automation is to create and manage your own Supabase project instead.
Neither page shows readers a published or updated date, so the only honest stamp is the read date: 17 August 2026.
The SQL editor contradiction, resolved
Lovable’s Cloud documentation lists SQL editor among the twelve Cloud tools, described as “Run SQL queries and commands against your database”. Supabase’s troubleshooting FAQ answers the question “Can I get access to the Supabase SQL editor when using Lovable Cloud?” with “No. Projects running on Lovable Cloud use a managed Supabase backend that doesn’t provide direct SQL editor access through supabase.com/dashboard.”
Both statements are correct and they describe different rooms. You get a SQL editor inside Lovable, on Lovable’s terms, for as long as you are a Lovable customer. You do not get one on an account that would still work if you stopped being one. That distinction is invisible while everything is fine and decisive the moment it is not.
Three ordinary requests show where that lands. A developer joins the project and asks you to send the connection string, and there is no connection string to send. An accountant wants the revenue table in a BI tool, and external connections are documented as unsupported. An automation in n8n or Make needs a service role key, and the documented answer is to stand up a separate Supabase project and move the app to it. Each of those takes a database account about thirty seconds. On Cloud each one is a project.
The reader this matters most to is the one who has not enabled Cloud yet, which is a narrow window, because Lovable’s documentation says the built-in backend is on by default for a workspace and gets switched on automatically the first time a prompt needs a database.
Who gets the bill for Lovable Cloud
One balance pays for everything. Lovable’s Cloud documentation states it directly: “Lovable uses one credit balance for building your app, hosting it and running its built-in backend (Cloud), and AI features in deployed apps.”
That sentence decides more than the price. Your visitors’ database traffic and your own ability to keep editing the app draw down the same pot, so a busy week for the app is a week with fewer credits left for building it. The meter behind that, meaning how Lovable credits are charged and what happens at zero, is a large enough subject to sit on its own page. The short version is that an empty balance stops building, stops AI features in the deployed app, and pauses the built-in backend services shortly afterwards.
On your own Supabase project the money splits, and Lovable’s integration documentation says so in its own comparison: billing on Cloud is credits in your Lovable workspace, while billing on a connected project is your Supabase subscription, billed by Supabase. Two invoices, two ceilings, two account owners. What a Supabase bill actually adds up to is a separate question from what Lovable charges, and worth pricing before the choice rather than after.
Someone on r/lovable, writing on 30 July 2026 after about a hundred credits of building, described the problem better than either vendor does. They had realised that “the end user (me testing for now) is eating credits away on my site” and wanted to know whether that was “normal/un-workaroundable”. It is normal. It is also the part that only becomes visible once somebody other than you uses the app.
That is where the choice stops being administrative. One of the 26 apps in the fixed audit corpus reviewed here across June and July 2026, an AI-powered content management system, shipped a passwordless login route that sent one-time codes with no rate limit, no cooldown and no authentication. A script could point at any inbox and keep it running, and every send drew on the same email quota the product paid for. The same app’s AI scanning endpoints were behind a session check and nothing else, unthrottled, and every call billed to one shared provider key. Both of those are ways for a stranger to spend the owner’s money without ever getting into the database.
An open expensive endpoint is a line item before it is anything else, and the choice made in the table above decides which account receives that line item. On Cloud it lands in the credit balance that also pays for your ability to fix the endpoint. On your own Supabase, the database bill is a separate invoice with its own limits and its own alerts, and the builder subscription keeps working while you deal with it.
What you can still do the day you want off Lovable Cloud
The exit is documented, and it is manual. Lovable’s Cloud documentation, read 17 August 2026, says that removing Cloud deletes the instance for good with no way to undo it, and tells you to export your database and download any storage files you need before you start. Supabase’s troubleshooting page says the same thing from its side of the boundary: there is no automated way to transfer a Cloud backend into your own Supabase account.
Two documented behaviours get mistaken for exits. Remixing a Cloud project produces another Cloud project, so the backend does not change hands. Migration in the opposite direction, from your own Supabase into Cloud, is not supported at all, so the door only swings one way and it is not the way most people assume. The region does not travel either: Lovable’s documentation says the hosting region is fixed once Cloud is enabled and existing projects cannot be moved between regions, and the three published options are Americas, Europe and Asia Pacific, joined in the picker by a Closest to me setting that resolves to whichever of the three is nearest, with country-specific regions available on Enterprise by request.
What you actually carry out is an export, and what the Lovable Cloud database export contains decides how much of the destination you rebuild by hand rather than restore.
The procedure itself is not on this page and should not be. Read what moving off Lovable Cloud actually involves and you get schema, data rows, storage files, auth providers and secret values, each behaving differently. The neighbouring questions are separate again: what the Lovable code export includes, moving the whole app off Lovable rather than only its backend, and what the move off Lovable costs once somebody has to do the work. None of them is a paragraph.
The reason to read this section before enabling Cloud rather than after is that every fact in it follows from one switch thrown on day one, often by the agent rather than by you.
Lovable Cloud or Supabase: which should you pick?
Neither option wins outright. Pick Cloud when the app is a prototype or an internal tool and nobody outside the builder needs the data. Pick your own Supabase when a developer will work on it, an external system must connect, or somebody else has to be able to receive the app.
The disqualifier is the clean one, and Supabase wrote it: if you plan to manage your Supabase project independently, its troubleshooting page advises against enabling Lovable Cloud in the first place. That is prevention advice from the vendor whose product is underneath both options, and it is the closest thing to a ruling either vendor gives.
- A developer is joining, now or later. Own Supabase. There is no connection string to hand them on Cloud.
- An external tool must read the data. Own Supabase. BI tools, Postgres clients, n8n and Make are documented as unsupported on Cloud.
- The app is a prototype, a demo, or an internal tool. Cloud, as long as nothing outside Lovable needs to connect and nobody needs to own the data or choose its region. The setup cost is zero and at that size the constraints rarely bite.
- A client or employer has to be able to receive the app. Own Supabase, in an account that can be transferred.
- You already have a Supabase account you use for other work. Own Supabase. Cloud would put this one project somewhere you cannot see it.
- You genuinely do not know yet. Own Supabase. The reversible choice is the one that starts in your account, because the other direction is documented as closed.
Worth saying plainly: most people never make this choice consciously, because Cloud is the default and the agent enables it mid-prompt. Someone posting to r/lovable on 13 August 2026 had a database, authentication and AI prompts already running on their own Supabase and still asked, “The backend is currently just code within Lovable, right? Would it be possible to move the backend to Supabase as well?” The vocabulary is genuinely unclear, and a decision made inside unclear vocabulary is not much of a decision.
The same backend choice on Base44, Bolt, Replit and v0
Every builder that ships a backend has to answer the same question, and they answer it differently enough that the answers are worth knowing before you pick a builder rather than after. Bolt is the sharp contrast: its documentation describes claiming your built-in database in Supabase, which migrates the Bolt database into your own Supabase organisation if you are that organisation’s owner, and it names external management tools, SQL editing and advanced monitoring as the reasons you might want to. That is the exact move Lovable’s Cloud documents rule out. How Base44 answers the same backend question is a longer comparison, and the builders that ask the backend question differently, including the ones with no repository at all, are worth a wider look than one table.
| Builder | Where the app data lives | Can you take the account? | Source, read 17 August 2026 |
|---|---|---|---|
| Lovable Cloud | A Supabase instance Lovable owns | No | Lovable Cloud docs |
| Bolt | Bolt Database by default, or Supabase selected at project creation | Yes, by claiming the Bolt database in Supabase as an org owner | Bolt Database docs for the default; Bolt Supabase docs for claiming |
| Replit | A managed SQL database inside the Replit app | Partly: the production connection string works from any Postgres client | Replit connection details |
| v0 | No database of its own; adding an integration provisions an account on Upstash, Neon, Supabase or Vercel Blob | Yes, the provider account is yours | v0 databases docs |
| Base44 | Base44’s own tables inside the platform | Not documented: as read on 17 August 2026 the data docs describe tables, exports and an API, and no database account outside Base44 | Base44 data docs |
Read the middle column, not the right one, if you are choosing a builder today. Replit hands out a production connection string that its documentation says works from any PostgreSQL-compatible client, which is a real portability step, though the table’s middle column shows Bolt going further by letting you claim the whole database into your own Supabase organisation. Base44 sits at the other end, where its data documentation describes no external database account to own. Lovable is unusual in running Supabase, the most portable backend on this list, in a way that produces none of the portability.
Common questions about Lovable Cloud and Supabase
Is it better to use Lovable Cloud or Supabase?
Better depends on who needs to touch the database. Cloud is better when nobody outside Lovable ever will, because it is faster to start and there is nothing to administer. Your own Supabase project is better the moment a developer, an external tool or a new owner enters the picture, because on Cloud none of those has a documented route in.
Is Lovable Cloud free or paid?
It is paid out of the same credit balance as everything else in Lovable, and Lovable’s Cloud documentation says the Free, Pro and Business plans include a monthly Cloud grant. How far that goes is a separate question with real numbers behind it: what the free plan’s monthly Cloud grant covers, and how quickly one busy feature can spend it, is measured elsewhere and deliberately not restated here.
Can I get my Lovable Cloud database URL or service role key?
No. Supabase’s troubleshooting documentation, read 17 August 2026, states that service role keys and direct database URLs are not available on a Cloud-managed project, and that the documented route to external automation is to create and manage your own Supabase project instead. There is no setting, tab or support request in either vendor’s published documentation that produces one.
Can I switch from Lovable Cloud to my own Supabase project?
No, not as a switch. Supabase’s documentation says Cloud cannot be disconnected or switched to an external Supabase connection once it is enabled, and that there is no automated way to transfer the backend. What is documented instead is a rebuild: export the Cloud data, create a Supabase project in your own account, connect it, and recreate the schema there.
How do I know which backend my Lovable project is using?
Open the Cloud settings inside the project. Supabase’s identify-backend page says the Cloud icon appears on every project regardless of backend, and that what you see after opening it tells you which one you have: screens for managing database tables and users inside Lovable means Cloud, while the Supabase icon, your Supabase project name and links out to the Supabase Dashboard means a project you own.
Is Lovable Cloud good enough for a real app with real users?
The backend underneath it is the same Postgres that runs plenty of production apps, so the constraint is ownership rather than capability. Cloud stops being good enough at the point where somebody outside the builder needs access, where an external system must connect, or where the app has to be handed over. Whether the app itself is ready is a different check entirely, and the tests that decide whether a Lovable app is ready for real users cover access rules, error handling and load rather than backend choice.
How do I enable Lovable Cloud, and can I turn it off?
Lovable’s documentation says the built-in backend is enabled by default at workspace level and gets switched on automatically, or after asking in chat, the first time a prompt needs backend functionality. Turning it off has one documented route, Remove Lovable Cloud under Cloud tab → Overview → Advanced settings, and that route deletes the instance permanently rather than switching the project to another backend. The documentation tells you to export first for exactly that reason.
Can I connect n8n, Make, or a BI tool to Lovable Cloud?
No. Supabase’s troubleshooting page states that external connections are not supported when a project runs on Lovable Cloud, and lists BI tools, Postgres connectors, n8n and Make.com as the cases people ask about. Connecting any of them means running the app on a Supabase project in your own account, which is a decision made before Cloud is enabled rather than after.
Built it with AI. Can’t get the last part right?
That’s the normal state of an AI-built app, and it’s fixable. I trace what the app actually does, explain what needs changing, and build it if you want me to.
Talk about your app → 
Free 20-minute video call with Bilal.