Lovable Cloud vs Supabase (2026): Where Your Data Lives, What It Costs and How to Move It

“I made a mistake of hosting my supabase on lovable cloud and now am looking for a safe way to migrate off of it.”— a Lovable builder on r/lovable, July 2026

Lovable Cloud vs Supabase comes down to control. Lovable Cloud is a Supabase backend that Lovable runs for you and bills in credits. Your own Supabase project gives you the dashboard, keys and direct database access, billed by Supabase. Moving from Cloud to your own project is possible today, but it is a manual job with hard limits.

1What is Lovable Cloud, exactly?

Supabase confirms the same from its side: every project created in Lovable Cloud “is powered by Supabase behind the scenes” (Supabase blog). The two companies have worked together since January 2025, when Lovable started creating Supabase projects through Supabase’s Management API (Supabase customer story).

The catch is ownership of the instance. With Cloud, the Supabase project is “owned and managed by Lovable.” It does not show up in your own Supabase dashboard, and you get no service role key and no direct database URL (Supabase docs). Cloud also locks your region (Americas, Europe or Asia Pacific) once it is enabled (Lovable docs). Not sure which one your project uses? Click the Cloud icon in the Lovable editor. A connected Supabase project shows the Supabase logo, the project name and links to its dashboard.

That is the whole idea behind this site: the part of an AI-built app that matters most once people use it sits beyond the UI. Your data, logins and payments live in the backend, and that is where most of the hard decisions are.

2Lovable Cloud vs Supabase: what is actually different?

Cloud also has a few features you lose when you leave. Lovable lists in-editor backend views, managed backups and resizing, Lovable-configured auth (including managed Google sign-in and SAML SSO), auth emails from your own domain and signed-in browser testing as Cloud-only (Lovable docs). If you rely on those, switching costs you more than an afternoon.

One warning about outdated advice. A Supabase troubleshooting page still says that once Lovable Cloud is enabled, a project “cannot be disconnected or switched,” and that there is no SQL editor (Supabase docs). Lovable’s current documentation shows both an SQL editor and a “Remove Lovable Cloud” option in Advanced settings (Lovable docs). The Supabase page describes an earlier state of the product. Many Reddit answers from late 2025 and early 2026 do too.

3What does each option cost in 2026?

Lovable bills Cloud by usage: the database server (instance size multiplied by active time), database storage, network, file storage, compute and realtime (Lovable docs). Lovable does not publish an hourly credit rate per instance size. The app shows an estimate when you resize, and your workspace usage page shows what Cloud actually used. That makes the Lovable side of any comparison personal: you need your own usage number.

The free Cloud grant has already changed once. At launch, Lovable described the free tier as usage “up to $25/month” (Lovable blog, 2025). The current docs say 20 credits a month and call it a “temporary offering, subject to change” (Lovable docs). Do not plan a business around it staying free.

Supabase’s free plan has two traps of its own. Free projects pause after one week of inactivity, and you can have at most two active free projects (Supabase pricing). Free projects also get no daily backups (Supabase docs). Lovable Cloud does keep daily backups, so moving a live app to Supabase Free means giving up backups you already had.

4Can you migrate from Lovable Cloud to your own Supabase?

The export arrives as a PostgreSQL custom-format .backup file, compressed with zstd, which you restore with pg_restore. You can also download any single table as a CSV from the Cloud database view (Lovable docs).

The official migration steps

Lovable’s guide “Host backend and data on a managed provider” walks through the move to Supabase (Lovable docs). In order:

1. Export your database in Advanced settings → Export project data, and download your storage files.
2. Create a new Supabase project.
3. Run the SQL files in your repo’s supabase/migrations/ folder, in order, to rebuild the schema.
4. Restore the export with pg_restore to load your data and users.
5. Set up auth again: sign-in providers, redirect URLs and API keys.
6. Upload your storage files to Supabase Storage.
7. Add your secrets to the new project.
8. Deploy your edge functions with the Supabase CLI.
9. Test on a separate deployment first.
10. Point .env and supabase/config.toml at the new project.

Step 3 explains one of the most common complaints on Reddit. Running the migrations rebuilds the tables, but not the rows inside them. One builder connected a fresh Supabase project and saw “table names with zero content” (r/lovable). The data only arrives with the restore in step 4.

What does not move by itself

Two more details matter before you start. “Remove Lovable Cloud” deletes the Cloud instance permanently, so export your database and storage first (Lovable docs). Lovable’s docs also describe two targets: the Cloud FAQ connects Supabase to a new Lovable project, while the hosting guide switches the same project by editing its config. Pick one before you begin.

You do not have to move the frontend to move the backend, or the other way round. Lovable syncs your code two-way with GitHub, GitLab or Bitbucket on all plans, and the frontend can run on Netlify, Vercel or Cloudflare Pages while it still talks to the Cloud backend (Lovable docs). Your database never ends up in the repo (Lovable docs).

5Will your users have to reset their passwords?

This is where community advice and the documentation disagree most. One commenter warned: “You must add new users. Don’t even attempt to reuse the logins” (r/lovable). Lovable’s own docs say the export carries the hashes (Lovable docs), and Supabase confirms that the auth schema, “including users and their hashed passwords,” can be moved so users “do not need to reset” their passwords (Supabase docs).

Why it works: Supabase stores passwords as bcrypt hashes in auth.users.encrypted_password (Supabase docs). Copy that column and the same password still matches. The bad experiences on Reddit mostly come from migrations that rebuilt the schema but never restored the auth data. Existing sessions do not carry over either, so everyone has to sign in once more, which can look like broken logins if you do not expect it (Lovable docs).

6Is your own Supabase project safer?

The core rule comes from Supabase: “A table in an exposed schema without RLS is readable and writable by any role with a grant on it” (Supabase docs). Row Level Security (RLS) that is switched on is not enough either. Supabase’s linter flags policies like USING (true) because an always-true condition “defeats the purpose” of RLS (Supabase lint 0024). As one Reddit post put it: “A permissive policy with RLS enabled is functionally identical to no RLS” (r/lovable).

Lovable has had RLS trouble before. CVE-2025-48757, rated 9.3 (critical), described insufficient RLS policies in Lovable-generated apps that let unauthenticated attackers read and write tables (CVE record). The researcher found 303 exposed endpoints across 170 of 1,645 showcased projects, and criticised Lovable’s scanner for checking only that a policy exists, not that it works (Matt Palmer). Note that the researcher works at Replit, a competitor.

The platform itself has had issues too. In April 2026, a researcher showed that a free account could read other users’ source code, database credentials and AI chats. The report sat with HackerOne for about 48 days. Lovable first said “we did not suffer a data breach,” then admitted that a February 2026 backend change had re-enabled access to chats on public projects (The Register, Computing).

But owning the database is not a shield. In February 2026, one Lovable-showcased app exposed 18,697 user records. Lovable’s security chief said the vulnerable database “is not hosted by Lovable,” which means it ran on the owner’s own Supabase project (The Register). Whichever option you choose, run the checks: Lovable’s quick scan looks at database access rules every time you open the publish dialog (Lovable docs), and on your own project the Supabase Security Advisor flags disabled RLS, missing policies and always-true rules (Supabase docs). Lovable itself says its scans “do not replace a thorough security review.”

7Should you stay on Lovable Cloud or switch?

The money question is often smaller than it looks. If your project uses a handful of Cloud credits a month, the 20-credit grant covers it and Cloud costs you nothing extra. A Supabase Pro project costs at least $25 a month. The case for moving is usually control, backups and portability, not price. Run your own numbers in the calculator above.

8Third-party migration tools

For the do-it-yourself route, there is also the Lovable MCP server. Its query_database tool runs SQL on a Cloud project with your full database permissions (Lovable docs), and one builder used it to pull auth.users with the original password hashes (r/Supabase). The official export remains the simpler path for most projects. If you are still choosing a builder, this comparison of Lovable alternatives covers Bolt, v0, Replit and others.

What builders say

Frequently asked questions

Sources

1. Lovable. “Lovable Cloud.” docs.lovable.dev/features/cloud. Accessed Oct 6, 2026.
2. Lovable. “Advanced settings.” docs.lovable.dev/features/advanced-settings. Accessed Oct 6, 2026.
3. Lovable. “Project usage.” docs.lovable.dev/features/project-usage. Accessed Oct 6, 2026.
4. Lovable. “Credits and usage.” docs.lovable.dev/introduction/credits-and-usage. Accessed Oct 6, 2026.
5. Lovable. “Pricing.” lovable.dev/pricing. Accessed Oct 6, 2026.
6. Lovable. “Host backend and data on a managed provider.” docs.lovable.dev/tips-tricks/external-deployment-hosting. Accessed Oct 6, 2026.
7. Lovable. “Database.” docs.lovable.dev/features/database. Accessed Oct 6, 2026.
8. Lovable. “Supabase integration.” docs.lovable.dev/integrations/supabase. Accessed Oct 6, 2026.
9. Lovable. “Security.” docs.lovable.dev/features/security. Accessed Oct 6, 2026.
10. Lovable. “Lovable MCP server.” docs.lovable.dev/integrations/lovable-mcp-server. Accessed Oct 6, 2026.
11. Lovable. “Introducing Lovable Cloud and AI.” lovable.dev/blog/lovable-cloud. 2025.
12. Supabase. “Pricing.” supabase.com/pricing. Accessed Oct 6, 2026.
13. Supabase. “Database backups.” supabase.com/docs/guides/platform/backups. Accessed Oct 6, 2026.
14. Supabase. “Identifying Lovable backend: Lovable Cloud or Supabase.” supabase.com/docs. Accessed Oct 6, 2026.
15. Supabase. “Can’t access Supabase project (Lovable Cloud).” supabase.com/docs. Accessed Oct 6, 2026.
16. Supabase. “Migrating auth users between projects.” supabase.com/docs. Accessed Oct 6, 2026.
17. Supabase. “Row Level Security.” supabase.com/docs. Accessed Oct 6, 2026.
18. Supabase. “Database linter: permissive RLS policy.” supabase.com/docs. Accessed Oct 6, 2026.
19. Supabase. “Lovable Cloud launch.” supabase.com/blog. 2025.
20. Supabase. “Lovable customer story.” supabase.com/customers/lovable. 2026.
21. Matt Palmer. “Statement on CVE-2025-48757.” mattpalmer.io. May 2025.
22. Intruder. “CVE-2025-48757.” cvemon.intruder.io. 2025.
23. Reeve. “Vibe-coded app security 2026.” reeve.page. August 2026.
24. The Register. “Lovable denies data leak.” theregister.com. April 20, 2026.
25. Computing. “Lovable flaw exposed source code, credentials and AI chats.” computing.co.uk. April 2026.
26. The Register. “Lovable app vulnerabilities.” theregister.com. February 27, 2026.