--- title: "Lovable Cloud vs your own Supabase: how to choose | Lovable Field Guide" description: "Lovable Cloud vs Supabase is close to a one-way door. The documented tradeoffs, the credit pool that bills your hosting, and what switching later really costs." lang: en json-ld: | { "@context": "https://schema.org", "@graph": [ { "@type": "WebSite", "@id": "https://prerenderlovable.com/#website", "url": "https://prerenderlovable.com", "name": "The Lovable Field Guide", "description": "A working journal on Lovable SEO: getting apps built with Lovable indexed, ranked and cited, plus the migration and integration work that comes with it.", "publisher": { "@id": "https://prerenderlovable.com/#organization" }, "inLanguage": "en" }, { "@type": "Organization", "@id": "https://prerenderlovable.com/#organization", "name": "The Lovable Field Guide", "url": "https://prerenderlovable.com" }, { "@type": "BlogPosting", "@id": "https://prerenderlovable.com/blog/lovable-cloud-vs-supabase#article", "headline": "Lovable Cloud vs your own Supabase: how to choose", "description": "Lovable Cloud vs Supabase is close to a one-way door. The documented tradeoffs, the credit pool that bills your hosting, and what switching later really costs.", "datePublished": "2026-09-11T00:00:00.000Z", "dateModified": "2026-09-11T00:00:00.000Z", "inLanguage": "en", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://prerenderlovable.com/blog/lovable-cloud-vs-supabase" }, "author": { "@type": "Organization", "name": "The Lovable Field Guide", "url": "https://prerenderlovable.com" }, "publisher": { "@id": "https://prerenderlovable.com/#organization" }, "keywords": "lovable cloud vs supabase, lovable cloud or own supabase, should i use lovable cloud, lovable built-in backend vs supabase, lovable cloud credits hosting cost", "articleSection": "Migration" }, { "@type": "BreadcrumbList", "@id": "https://prerenderlovable.com/blog/lovable-cloud-vs-supabase#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://prerenderlovable.com/" }, { "@type": "ListItem", "position": 2, "name": "Migration", "item": "https://prerenderlovable.com/migration" }, { "@type": "ListItem", "position": 3, "name": "Lovable Cloud vs your own Supabase: how to choose", "item": "https://prerenderlovable.com/blog/lovable-cloud-vs-supabase" } ] }, { "@type": "FAQPage", "@id": "https://prerenderlovable.com/blog/lovable-cloud-vs-supabase#faq", "mainEntity": [ { "@type": "Question", "name": "Can I switch from Lovable Cloud to my own Supabase later?", "acceptedAnswer": { "@type": "Answer", "text": "Not with a button. Lovable's Supabase docs state there is no one-click migration from the built-in backend to Supabase or the other way. The documented path is manual and amounts to a rebuild rather than a setting: export your Cloud data, create a new Lovable project, connect a Supabase project to that new project, and rebuild the schema there." } }, { "@type": "Question", "name": "Can I move from my own Supabase onto Lovable Cloud?", "acceptedAnswer": { "@type": "Answer", "text": "No. Lovable's Cloud documentation says that at the moment, migration from Supabase to Cloud is not supported. Existing Supabase-connected projects keep working and remain supported, but there is no documented route to fold one back into the built-in backend." } }, { "@type": "Question", "name": "Does Lovable Cloud give me a Supabase dashboard I can log into?", "acceptedAnswer": { "@type": "Answer", "text": "No. Cloud is built on Supabase's open-source foundation, but it does not create a Supabase account, organization or project for you. You administer everything inside the Lovable editor under the More tab's Cloud section: database viewer, SQL editor, users and auth, storage, secrets, jobs, edge functions, logs and usage analytics." } }, { "@type": "Question", "name": "Does bringing my own Supabase stop Lovable charging me credits?", "acceptedAnswer": { "@type": "Answer", "text": "Only partly: messages you send the agent still cost build credits. Database, storage and realtime usage moves onto your own Supabase bill, and Lovable's docs list no per-project cost to Lovable as an own-Supabase advantage. As of September 2026 the docs do not spell out which Cloud metering lines still apply to a Supabase-connected app on Lovable hosting, so check your usage analytics rather than assuming zero." } }, { "@type": "Question", "name": "Which is enabled by default on a new Lovable project?", "acceptedAnswer": { "@type": "Answer", "text": "Lovable Cloud. The docs state that by default the built-in backend is enabled for your workspace, so doing nothing is itself a choice. If you want your own Supabase, link the Supabase organization to the workspace and connect the project before you ask the agent for tables." } }, { "@type": "Question", "name": "What actually happens if I run out of credits with Lovable Cloud?", "acceptedAnswer": { "@type": "Answer", "text": "Per Lovable's credits documentation, building stops, AI features in your deployed app fail, and backend services pause. Your data remains safe. The point is that a credit shortfall reaches your live application as well as your editor, because hosting usage and AI coding draw on the same balance." } } ] } ] } --- [Skip to content](#main) [Lovable Field Guide ](/) [SEO](/seo)[Migration](/migration)[Integrations](/integrations)[All posts](/blog) [Start here](/blog/lovable-seo) [SEO](/seo)[Migration](/migration)[Integrations](/integrations)[All posts](/blog) 1. [Home](/) 2. / [Migration](/migration) 3. / Lovable Cloud vs your own Supabase: how to choose # Lovable Cloud vs your own Supabase: how to choose Lovable Cloud vs Supabase is close to a one-way door. The documented tradeoffs, the credit pool that bills your hosting, and what switching later really costs. Published September 11, 2026 · 11 min read 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](/blog/lovable-migration) alongside this one. The short version Throwaway or short-lived project: Cloud. Anything you will hand to someone else, sell, raise money on, or run for real users: your own Supabase, created in the org that should own it long-term. Lovable Cloud is enabled by default, so not deciding means deciding for Cloud. ## What you are actually choosing between[#](#what-you-are-actually-choosing-between) ### Lovable Cloud[#](#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[#](#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[#](#the-documented-tradeoffs-both-directions) These are the advantages Lovable itself documents for each side. Lovable Cloud Your own Supabase Setup Zero. On by default Link a Supabase org, then connect the project Billing No separate account or bill: draws on Lovable credits Your own Supabase account and billing, separate from Lovable Admin surface In-editor database and user management views Full Supabase dashboard, plus the in-editor views Infrastructure Managed: backups and scaling handled for you Direct infrastructure control, and the responsibility that comes with it External access No Supabase project of your own to point tools at Supabase’s REST API for external integrations Auth setup Configured through Lovable chat Supabase Auth, configured by you Secrets Lovable’s secret store Your Supabase project’s secrets Cost to Lovable Cloud usage consumes credits Documented as no per-project cost to Lovable Switching later No supported migration in either direction No supported migration in either direction 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[#](#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. Gotcha Lovable’s hosting docs say your plan does not cap visitors, requests or bandwidth. That’s about plan limits. Runtime usage still costs credits. Cloud usage still meters, so “unlimited traffic” and “unlimited spend” are not the same sentence. 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](/blog/save-lovable-credits) 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[#](#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](/blog/lovable-cloud-to-supabase). Warning Leaving Lovable Cloud is not the same as leaving Lovable. You can keep building in the editor with your own Supabase behind it. People conflate the two and delay the decision, which is the expensive order to do things in. ## Which to pick, by scenario[#](#which-to-pick-by-scenario) Scenario Pick Why Weekend project, demo, internal toy **Cloud** Zero setup, and nothing is locked in that you’d mind losing. The Cloud grant is 20 credits a month and doesn’t roll over; Lovable doesn’t publish what that buys in database or bandwidth terms, so read the usage analytics view rather than assuming a quiet app is free Prototype you expect to rebuild properly later **Cloud** The rebuild _is_ the migration. Paying setup cost twice for a throwaway is waste Client work or agency build **Your own Supabase**, in the client’s org Handover spans the workspace, repo, deployment, database, domain and secrets. Cloud makes the database the one piece you cannot cleanly transfer Funded startup, or anything facing diligence **Your own Supabase** “The data lives inside our app builder’s managed backend with no direct access” is a bad answer under time pressure, and that is exactly when it gets asked Real users with passwords **Your own Supabase** A forced password reset for your entire user base is the migration cost you cannot pay quietly later Traffic-heavy or spiky workload **Your own Supabase** Separates hosting cost from build budget so one bad week doesn’t stop you shipping You need SQL access from other tools, BI or services **Your own Supabase** Supabase’s REST API and dashboard exist; Cloud gives you neither No one on the team can administer Postgres **Cloud**, deliberately Managed backups and scaling are a real feature. Just write down that you chose it and why ## What doesn’t change either way[#](#what-doesnt-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](https://encited.com/blog/lovable-seo-update) 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](/blog/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[#](#if-youre-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](/blog/lovable-github-sync) early, so the migration files and function source are somewhere you control. ## What to do next[#](#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. Found something wrong or out of date? Lovable changes fast and we'd rather fix a guide than let it rot. Disclosure: the team behind this guide also builds Encited, mentioned above. On this page - [What you are actually choosing between](#what-you-are-actually-choosing-between) - [Lovable Cloud](#lovable-cloud) - [Your own Supabase](#your-own-supabase) - [The documented tradeoffs, both directions](#the-documented-tradeoffs-both-directions) - [The factor most comparisons miss: one wallet for building and running](#the-factor-most-comparisons-miss-one-wallet-for-building-and-running) - [Switching later: manual in one direction, unsupported in the other](#switching-later-manual-in-one-direction-unsupported-in-the-other) - [Which to pick, by scenario](#which-to-pick-by-scenario) - [What doesn’t change either way](#what-doesnt-change-either-way) - [If you’re going with your own Supabase, do it in this order](#if-youre-going-with-your-own-supabase-do-it-in-this-order) - [What to do next](#what-to-do-next) [More on Migration](/migration) - [Getting your code out of Lovable: the full guide](/blog/lovable-migration) - [How to download your code from Lovable](/blog/download-lovable-code) - [Lovable Cloud vs your own Supabase: how to choose](/blog/lovable-cloud-vs-supabase) - [Lovable GitHub sync: how it really works](/blog/lovable-github-sync) - [Migrating from Lovable Cloud to your own Supabase](/blog/lovable-cloud-to-supabase) - [Moving a Lovable project to a different repo](/blog/move-lovable-project-to-another-repo) - [Running an exported Lovable app on your machine](/blog/run-exported-lovable-app-locally) - [Self-hosting a Lovable app, and what you lose](/blog/self-host-lovable-app) ## Frequently asked questions Can I switch from Lovable Cloud to my own Supabase later? Not with a button. Lovable's Supabase docs state there is no one-click migration from the built-in backend to Supabase or the other way. The documented path is manual and amounts to a rebuild rather than a setting: export your Cloud data, create a new Lovable project, connect a Supabase project to that new project, and rebuild the schema there. Can I move from my own Supabase onto Lovable Cloud? No. Lovable's Cloud documentation says that at the moment, migration from Supabase to Cloud is not supported. Existing Supabase-connected projects keep working and remain supported, but there is no documented route to fold one back into the built-in backend. Does Lovable Cloud give me a Supabase dashboard I can log into? No. Cloud is built on Supabase's open-source foundation, but it does not create a Supabase account, organization or project for you. You administer everything inside the Lovable editor under the More tab's Cloud section: database viewer, SQL editor, users and auth, storage, secrets, jobs, edge functions, logs and usage analytics. Does bringing my own Supabase stop Lovable charging me credits? Only partly: messages you send the agent still cost build credits. Database, storage and realtime usage moves onto your own Supabase bill, and Lovable's docs list no per-project cost to Lovable as an own-Supabase advantage. As of September 2026 the docs do not spell out which Cloud metering lines still apply to a Supabase-connected app on Lovable hosting, so check your usage analytics rather than assuming zero. Which is enabled by default on a new Lovable project? Lovable Cloud. The docs state that by default the built-in backend is enabled for your workspace, so doing nothing is itself a choice. If you want your own Supabase, link the Supabase organization to the workspace and connect the project before you ask the agent for tables. What actually happens if I run out of credits with Lovable Cloud? Per Lovable's credits documentation, building stops, AI features in your deployed app fail, and backend services pause. Your data remains safe. The point is that a credit shortfall reaches your live application as well as your editor, because hosting usage and AI coding draw on the same balance. Read next ## Keep going - ### [Migrating from Lovable Cloud to your own Supabase](/blog/lovable-cloud-to-supabase) There is no one-click Lovable Cloud to Supabase migration. The honest manual runbook: export, schema, RLS, edge functions, storage, secrets, auth and rollback. - ### [Getting your code out of Lovable: the full guide](/blog/lovable-migration) A Lovable migration is really three migrations: frontend, backend, hosting. What each export path moves, which one-way doors break sync, and the safe order. - ### [How to spend fewer credits on Lovable](/blog/save-lovable-credits) Save Lovable credits by understanding what a credit actually buys: per-message billing, three kinds of usage in one pool, and the rollover rules. The Lovable Field Guide A working journal on Lovable SEO. SEO - [SEO hub](/seo) Migration - [Migration hub](/migration) Integrations - [Integrations hub](/integrations) © 2026 The Lovable Field Guide. Independent guides to shipping Lovable apps. [RSS](/rss.xml) [Sitemap](/sitemap.xml) [About](/about)