The short version
You went looking for the Supabase SQL editor everyone talks about, and your project does not have one. That is the moment most people find out what Lovable Cloud is. It runs on Supabase technology, and Lovable holds the account. Your data is not lost and it is not stolen. It is just somewhere you cannot reach directly.
Here is the whole answer before the detail. Lovable Cloud is a managed backend built on Supabase's open-source foundation. You can export the database. The export leaves behind your storage files, your edge function code and your secrets, and Lovable says your users' passwords do not come across in a usable form. There is no one-click move. And most readers of this page should not move at all yet.
That last sentence costs us work, and it is still the right advice for the majority of people who arrive here.
Is Lovable Cloud just Supabase?
Close, but the difference is the part that matters to you. Lovable's documentation describes Cloud as a built-in backend covering database, authentication, storage, edge functions and AI, and says it "utilizes Supabase's open-source foundation, which means you get a production-ready environment from day one, without needing to set up Supabase separately". So underneath is Postgres, and the moving parts behave the way Supabase behaves.
What changes is whose account it sits in. When Lovable provisions Cloud for you, Lovable manages the instance. When you connect your own Supabase project instead, Lovable's docs describe what you get in plain terms: "direct ownership of the backend: your own Supabase account and billing, full access to the Supabase dashboard".
So the honest framing of this decision is not Cloud versus Supabase, because both are Supabase. It is managed-for-you versus owned-by-you. Everything else follows from that one distinction.
Who owns the database behind a Lovable Cloud app?
Lovable runs the instance, and the practical consequences show up in small ways before they show up in big ones. You cannot open a Supabase dashboard you control. You cannot hand a connection string to a contractor or point a reporting tool at your own tables. You cannot take a backup on your own schedule in the way you would with a project in your name.
For a lot of apps that is a perfectly reasonable trade, and it is the trade Cloud exists to make. It stops being reasonable at a specific moment, and it is usually one of three. A customer sends you a security questionnaire asking where their data lives and who can reach it. An auditor asks the same thing in writing. Or you need to do something ordinary and technical, like a bulk data fix or a nightly export into your warehouse, and there is no door to go through.
The word people reach for is "locked in", and it overstates it. There is an exit. It has steps, and the steps have edges worth knowing about before you start.
Should you move off Lovable Cloud at all?
Probably not today. We will say that plainly, because every other page competing for this search is written by somebody who sells the migration.
Stay on Lovable Cloud if all of these are true. You have a small user base. You take no payments. You hold no personal data beyond an email address. Nobody has asked you a compliance question. Your app is still changing shape week to week. In that situation a migration gives you a backend you now have to run yourself, in exchange for control you are not using. Spend the week on the product instead.
Move when one of these is true. You need direct Postgres access for reporting, analytics or a bulk operation the chat interface will not do. A customer contract or an audit requires you to hold the data in an account you control. You are hiring an engineer or an agency and they need real credentials to work. You have hit a limit on the managed instance that you cannot design around. Or you want the billing relationship for the backend in your own name, which is what Lovable's docs describe as the difference.
One more case, and it is the one we see most. You are not moving because Cloud is bad. You are moving because the app worked, it now has customers, and the thing you built in a weekend has quietly become the thing your business runs on. That is a good problem and it deserves a planned migration rather than a panicked one.
What does the Lovable Cloud export actually contain?
Your tables and your rows. Not your files, not your functions, not your secrets, and not your users' passwords. That is the whole answer, and the gap between it and what most people assume they are getting is where migrations go wrong.
The export itself is real and it is the right starting point. Lovable added Export, Pause and Remove controls in the Cloud tab under Advanced settings in July 2026, and before that the exit was genuinely awkward. Credit where it is due. It is just narrower than the word "export" suggests.
According to Lovable's documentation, the export gives you the database structure and data, and excludes "files in storage buckets, edge function code, or your project's secrets". The same page states that "User passwords are not exported in a usable form either", that database exports are limited to 5 GB, and that you can request one export every 24 hours.
| What you are moving | In the official export? | How it actually travels |
|---|---|---|
| Tables, columns, rows, constraints | Yes | Restore the backup into your own Postgres |
| Row Level Security policies | Yes, as part of the schema | Verify each one after restore, do not assume |
| Storage bucket files | No | Download separately, re-upload, fix the URLs |
| Edge function code | No | Recover from your repo and redeploy by hand |
| Project secrets and API keys | No | Re-create every one in the new project |
| User passwords | Not in a usable form, per Lovable's docs | Plan a reset flow. See the next section |
Read the right-hand column again. Four of those six rows are work you do yourself after the export finishes. That is what Lovable means when its documentation says, flatly, that "There is no one-click migration from the built-in backend (Cloud) to Supabase or the other way". The export is a database backup. A backup is not a migration.
What happens to your users and their passwords?
Plan this part first, because it is the only step your customers will notice.
Lovable's documentation says user passwords are not exported in a usable form. Taken at face value, that means the people already signed up to your app cannot log in with their existing password once you switch backends, and you need a password reset flow and an email to every user before you cut over.
Now the awkward part, and we would rather show you the conflict than pretend it is settled. Several third-party migration tools advertise the opposite, describing transfers that carry the auth schema across with password hashes intact and OAuth identities re-linked so nobody has to re-authorise. Both claims are in public today and they cannot both be right for the same export file. We have not been able to verify which is current, so we are not going to tell you.
What we will tell you is how to settle it in ten minutes, for your project, which is the only answer that matters. Take the export, open the auth schema, and look at the user rows. If there is a usable password hash per user, a silent switchover is on the table. If the field is empty, redacted or missing, you are sending reset emails, and it is far better to know that now than on the morning of the cutover. Check your own file. Do not take a vendor's word for it, including ours.
If your app has paying customers, do not cut over until you have proved a test user can log in on the new backend. One test account, one real login, before you touch production.
How do you move a Lovable Cloud database to your own Supabase?
The order below exists to keep a working app in front of your users the entire time. Nothing here deletes anything until the last step, and the last step is not on the same day as the first.
- Create your own Supabase project first. Empty, in your account, in the region closest to your users. You now have a place to land before you have moved anything.
- Export from Lovable. Cloud tab, Overview, Advanced settings. Remember the cap of one export every 24 hours, which means a botched export costs you a day. Save the file somewhere you will still have it next week.
- Download your storage files separately. They are not in the export. Keep the bucket and path structure intact so the URLs your app builds still resolve after you re-upload.
- Restore the database into the new project using Postgres command line tools. It will print errors. Extensions, roles and ownership statements are the usual ones, and most are noise rather than data loss. Read every error rather than scrolling past them.
- Re-create your secrets and API keys in the new project. Nothing carries over. This is also the moment to stop reusing any key that has ever been near a browser bundle.
- Redeploy your edge functions from your repository. The code was never in the export, so if it only ever lived inside Lovable, recover it before you remove anything.
- Check Row Level Security on every table, one at a time. Policies travel with the schema, and travelling is not the same as working. Log in as a second test user and try to read the first user's rows. If you can, you are not finished. Our vibe coding security checklist covers the service-role key trap that makes policies look correct while doing nothing.
- Point the app at the new backend and run it in parallel while the old one is still alive. Sign up, log in, upload a file, trigger a function, make a payment if you take them.
- Only then deal with the old instance. Pause before you remove. See the next section.
None of these steps is difficult on its own. What makes migrations go badly is doing them in the wrong order, or doing them on a Friday, or discovering at step seven that step six was never possible because the function code is gone.
What to check before you press Remove
Lovable's documentation is direct about this one. Removing Lovable Cloud "permanently deletes your Cloud instance and cannot be undone", and the flow asks you to confirm that unexported data may be lost. There is no support ticket that reverses it.
Pause exists for exactly this reason and it is the safer intermediate step. Lovable's docs note that while paused your backend is unavailable and the deployed app cannot read or write, and that storage usage continues while the project is paused because your data stays in place. So pausing proves your new backend is genuinely carrying the load, while the old one is still recoverable if it is not.
Run through this list before the irreversible click. Your new project serves real traffic. A test user has logged in successfully on the new backend. Storage files resolve, not just exist. Every edge function has been triggered at least once. You have a copy of the export file stored somewhere other than the laptop you are working on. And you have checked Row Level Security from a second account rather than from the dashboard.
If any one of those is unchecked, pause and wait. The instance costs you time, not certainty, and certainty is the thing you are buying here.
When it is worth handing this to someone
You can do all of this yourself. Plenty of people do, and if your app is small you probably should.
It gets harder in three specific situations. When you have live paying customers and no maintenance window. When the auth question above resolves badly and you need a reset flow that does not read like a security incident to your users. And when the edge functions and secrets were only ever configured inside the builder, so there is no repository to redeploy from and the logic has to be reconstructed before anything can move.
That is the work we do at Geminate Solutions. We take apps built on Lovable, Bolt and v0 and move them onto infrastructure the founder actually controls, without rewriting the product to justify the invoice. You own the account, you own the code, and you get the migration plan in writing before we touch anything. We have shipped 50+ products and we are Top Rated Plus on Upwork at 4.9. Read how we take AI-builder apps to production, or see whether yours is even ready for it in our Lovable production-readiness check.
Still deciding between backends rather than moving between them? Our Supabase versus Firebase comparison is the better page for that question.
Frequently Asked Questions
Is Lovable Cloud the same thing as Supabase?
Not quite. Lovable's docs say Cloud is built on Supabase's open-source foundation, so the database underneath is Postgres. The difference is the account. Lovable manages the Cloud instance. Your own Supabase project comes with your own dashboard and billing.
Can I use my own Supabase project with Lovable instead?
Yes, and Lovable documents it as the ownership option. You give up some conveniences by doing it, including in-editor backend views, built-in payments, custom email and configuring auth through chat.
How big can the export be?
Lovable's documentation puts the cap at 5 GB, with one export allowed every 24 hours. If your database is larger than that, sort it out before migration day rather than on it.
Will my Row Level Security policies survive the move?
They travel with the schema, which is not the same as working. Test every table from a second user account after the restore. A policy that exists and does nothing is the failure mode here.
What is the most common mistake you see?
Pressing Remove too early. It cannot be undone, and it is usually done by somebody who verified the tables restored and never checked that storage files, secrets and edge functions made it across.
