Lovable Cloud vs your own Supabase: how to choose

Choose Lovable Cloud when getting a working backend today matters more than owning it. Choose your own Supabase when the project has a future you care about: a client, a company, an acquirer, a handover. Lovable’s own docs say there is no one-click migration in either direction, which makes this close to a one-way door at project creation.

That single sentence is why this post exists. Most comparisons treat the choice as a convenience-versus-control tradeoff you can revisit. Only at real cost, and the second half of this post is about what revisiting it actually costs. For the wider picture of what does and does not leave Lovable when you export, read the Lovable migration guide alongside this one.

What you are actually choosing between#

Lovable Cloud#

Cloud is the backend bundled with Lovable hosting: database, authentication, storage, realtime and edge functions with no infrastructure setup. It is built on Supabase’s open-source foundation, and Lovable’s docs say it is enabled by default for your workspace.

You administer all of it inside the editor, under the More tab’s Cloud section: a database viewer for tables, records, security policies and backups, a SQL editor, users and auth, storage buckets, secrets, jobs for scheduled tasks, edge functions, logs, usage analytics and advanced settings. That is a real admin surface.

What it does not include is a Supabase account, organization, project or dashboard of your own. As of September 2026 Lovable’s docs describe no direct external database access to Cloud outside the editor, which is the part people discover late: there is no dashboard login to hand a contractor, and no project credentials to point a BI tool or a separate service at.

Your own Supabase#

Connecting your own Supabase is a two-level flow, and the levels matter for ownership. A workspace owner or admin links a Supabase organization to the Lovable workspace, making it available to everyone in that workspace. Then anyone with edit access connects a specific Lovable project to a Supabase project inside that linked org. Individual teammates do not each need their own Supabase account once the org is linked.

From then on, Lovable writes the SQL for schema changes, shows it to you, and asks for approval before running it, and the migration files are saved into your project code. Your schema history ends up in your repository, which is a quiet but significant difference. You still submit API keys through Lovable’s own secret form, but they come to rest in your Supabase project rather than in Lovable’s secret store; a Stripe key, for example, syncs to edge function secrets in your Supabase dashboard instead of appearing in Lovable’s Secrets view with a Lovable badge.

The documented tradeoffs, both directions#

These are the advantages Lovable itself documents for each side.

Read the last row twice. It is symmetrical and it is the whole decision.

The factor most comparisons miss: one wallet for building and running#

Lovable bills three different kinds of usage from a single unified credit pool:

1. Build usage: messages you send the agent to plan, generate, edit or update your app.
2. Cloud usage: database, network, storage, compute and realtime in your deployed app.
3. AI Gateway usage: model calls your deployed app makes at runtime.

Your hosting bill and your development budget are therefore denominated in the same unit and drawn from the same balance. A month of unexpected traffic does not arrive as a separate infrastructure invoice; it quietly removes the credits you were going to spend shipping features. That coupling is the strongest structural argument for bringing your own Supabase.

The blast radius when the balance hits zero is the second half of the argument. Lovable’s credits documentation is explicit: building stops, AI features in your deployed app fail, and backend services pause. Your data remains safe, but a credit shortfall is a production incident.

Three more mechanics worth knowing before you commit:

• The Cloud grant is small and does not roll over. Usage-specific grants refresh automatically and never carry forward: 20 Cloud credits per month, plus the daily build grant and a small monthly AI grant. General plan credits do roll over, but monthly-plan credits expire two months after issue. Spend order is grants first, then whichever general credits are closest to expiry.
• Top-ups are $0.30 per credit on Pro and $0.60 on Business. Multiple third-party pricing articles quote $0.25 and $0.50; the official credits doc does not. Free cannot top up at all. Auto top-up fires below a threshold you set and respects a monthly spend limit: set that limit on day one.
• Nothing in the meter distinguishes wanted requests from a bug. A client-side render loop that refetches on every render, or a scheduled job that polls often enough to keep the database from ever going idle, is billed exactly like real traffic. On Cloud that lands on the same balance you use to fix the bug. If credit burn is your main worry, cutting Lovable credit usage is a separate discipline worth reading up on.

With your own Supabase, database, storage and realtime usage lands on Supabase’s bill under Supabase’s own pricing, and Lovable’s docs list “no per-project cost to Lovable” among the advantages. Be careful about what that buys you: two bills is not automatically cheaper than one, it is legible. You get a hosting cost you can forecast independently of how much you talk to the agent, which is exactly what you want when someone else is paying.

Switching later: manual in one direction, unsupported in the other#

Lovable’s Supabase integration page states it plainly: there is no one-click migration from the built-in backend to Supabase or the other way. The Cloud page adds that migration from Supabase to Cloud is not supported at the moment. So:

Supabase to Cloud: no documented path. Existing Supabase-connected projects keep working and remain supported, but there is no route back into the built-in backend.

Cloud to Supabase: manual. The path Lovable documents is export your Cloud data, create a new Lovable project, connect a Supabase project to that new project, and rebuild the schema there. Note the sting in “new project”: it is not an in-place swap, so the original project’s continuity goes with it. Remixing a Cloud project just produces another Cloud project.

Independent migration guides published since Lovable added a data export action report a second route (remove Cloud from the existing project and connect your own Supabase to that same project) with the strong caveat that removal is permanent, moves no data for you, and therefore belongs at the very end of the process rather than the start. Treat either route as something you rehearse against a test restore before you attempt for real.

The data is the easy part. What those guides consistently report goes missing:

• User passwords. Reported as not exported in a form that keeps sign-in working, which means a forced password reset for every existing user. Treat it as a customer-communications project.
• Secret values. Lovable secrets are write-only: the store shows a name and a creation date, never a value. Every key gets regenerated at the provider and re-entered at the destination.
• Edge functions. Not in the database export. The source comes over with your code; deployment and secrets are yours to redo, and the failure mode is silent until a specific code path runs.
• Storage objects. Rows containing object paths restore perfectly while every linked file returns 404, and any signed URL stored in the database with a token= parameter is dead on arrival.
• Everything that isn’t code or rows. Scheduled jobs, OAuth redirect URIs and inbound webhooks keep pointing at the old backend. Guides report that Cloud handles Google sign-in through Lovable’s own libraries rather than Supabase directly, so those credentials get recreated rather than moved.
• Export throttling. Reported limits of 5 GB per export and one export request per 24 hours. A failed attempt costs you a day, which turns migration into a single-shot operation.

Ordering and verification for the full sequence live in moving from Lovable Cloud to your own Supabase.

Which to pick, by scenario#

What doesn’t change either way#

Worth being fair about, because plenty of comparisons imply otherwise:

• Both are Postgres, and Lovable documents Supabase Auth in either configuration, but Cloud’s auth is configured through Lovable chat, and guides report Cloud routes Google sign-in through Lovable’s own libraries, so the auth layer is not portable even though the name is the same. Clerk is not a documented Lovable integration in either configuration; it would go through the generic “integrate any API” path.
• Row-level security is your responsibility in both. Neither option writes correct policies for you.
• Build messages cost the same credits either way. Bringing your own Supabase reduces your runtime costs. Your agent bill stays the same.
• Publishing is still Lovable’s snapshot action. Pushing commits to a synced repo never updates the live site, regardless of backend.
• Your backend choice doesn’t change what crawlers get, and neither does the stack on its own. Lovable’s docs describe new (13 May 2026 onward) TanStack Start projects as returning fully rendered HTML, but Lovable’s generated code still fetches most dynamically loaded content (products, listings, profiles, prices: anything that isn’t written into the page’s source code) from a React hook after hydration, against the visitor’s session. None of that reaches the cached HTML, on Cloud or on your own Supabase. Check a page with dynamically loaded content: curl -sS https://yourdomain.com/products | grep -c 'product-card', then compare with what you count in the browser. The gap is the whole problem, and Lovable SEO covers what to do about it.
• On the Free plan there are no code downloads, no code editing and no custom domains, so “I’ll export later if it goes badly” is not a plan you actually have until you’re paying.

If you’re going with your own Supabase, do it in this order#

1. Create the Supabase project first, inside the organization that should own it for the life of the product: the client’s org or the company’s. Retrofitting ownership later is where things break.
2. Have a workspace owner or admin link that Supabase org to the Lovable workspace.
3. Connect the Lovable project to the Supabase project before you ask the agent for any tables. Schema created under Cloud does not follow you across.
4. Read the SQL migrations Lovable proposes before approving them. They land in your code, so your schema history is versioned in git from the first table onward.
5. Supply integration keys through Lovable’s secret form when the agent asks for them, then confirm they arrive as edge function secrets in your Supabase dashboard rather than in Lovable’s Secrets view with a Lovable badge.
6. Turn on git sync early, so the migration files and function source are somewhere you control.

What to do next#

• If the project doesn’t exist yet, make this call now and write one line in the repo README saying which backend you chose and why. It is the cheapest documentation you will ever produce.
• If you’re already on Cloud and the project is small or disposable, stay. Migrating a weekend app to prove a point is a bad trade.
• If you’re on Cloud and the project matters, check your database size against the reported 5 GB export cap today, then rehearse an export before you need one.
• Set a monthly spend limit and an auto top-up threshold on whichever side you land on. On Cloud it caps a runaway app; on Supabase it caps a runaway agent.
• Open the Cloud usage analytics view and look at what your deployed app is currently spending per day. If that number surprises you, you have your answer.