Lovable Export Database: What Comes Across and What Stays Behind

Lovable’s export documentation and the highest-ranking tool for the same job disagree about whether your users’ passwords survive the move. Both are telling the truth about two different paths, and which path you take decides whether every customer meets a forced password reset on cutover morning. The file Lovable emails you holds every table and every row you have. Four other things your app runs on were never in it.

Migrations come up constantly in my audit work, 26 AI-built apps so far, and they are where the distance between “I have my data” and “I have my app” turns into a support queue. This post covers what the export button moves, why the pg_dump instructions you’ll find elsewhere have nothing to point at on Lovable Cloud, and the restore-and-verify pass that proves the export is complete while the old project still exists.

What does the Lovable Cloud database export actually include?

The Lovable Cloud export is a full copy of your database, structure and data, capped at 5 GB with one export permitted every 24 hours. Four things your app depends on sit outside it: files in storage buckets, edge function code, project secrets, and your users’ passwords in any form you can sign them in with.

That list is not an inference. Lovable’s advanced-settings documentation says the export “contains your full database, both structure and data,” that “it does not include files in storage buckets, edge function code, or your project’s secrets,” and then, plainly: “User passwords are not exported in a usable form either.” A separate ownership and portability page calls your database, storage, and configuration portable, then names what complicates that: Lovable applications “rely on Supabase-specific services such as authentication, storage, realtime, and edge functions.”

Are you on Lovable Cloud, or on your own Supabase project?

Two Lovable backends exist and they leave by different doors. Lovable Cloud is the managed backend Lovable provisions for you, where the Export data button is the supported way out. A project wired to your own Supabase account already sits in a dashboard you control, with a connection string, a service-role key, and the full native toolchain.

If you can open supabase.com/dashboard and see the project your app talks to, you already have the tooling the rest of this post works around. If your backend only appears inside Lovable’s Cloud tab, keep reading. Whether to make the move at all is a separate call, covered in when moving off Lovable Cloud is the wrong decision, and if the destination is still open, the Supabase alternatives compared on what you own after the switch is the shortlist worth reading first.

How do I export my Lovable Cloud database to my own Supabase project?

The export path is five clicks and then a wait. Open the Cloud tab, then Overview, then Advanced settings, find Export project data, click Export data, and confirm with Export on the Database card. Lovable emails you when the file is ready and saves it into your project’s own Cloud storage, so the download happens from the Cloud tab under Storage.

1. 01 Cloud tab → Overview → Advanced settings → Export project data → Export data, then Export on the Database card.
2. 02 Wait for Lovable’s email. The export is generated in the background, not handed to you at the click.
3. 03 Download the file from Cloud tab → Storage, where Lovable saves it into your own project storage.
4. 04 Create the destination Supabase project first, and keep both projects alive until the checks further down have passed.
5. 05 Load the export into the new project and run the row-count comparison below before you trust it.
6. 06 Leave the Remove button alone until every item in the completeness check has passed on the new project, not the old one.

Two hard limits shape the schedule. Exports are capped at 5 GB and permitted once every 24 hours, so a botched attempt costs you a full day. Run the export a few days ahead of cutover, not on the morning of it. Lovable publishes no chunked export for a database over the cap, leaving two options: get under 5 GB by archiving out whichever table carries the bulk, or use one of the credential-extracting tools below.

Can I get a Postgres connection string to run pg_dump on Lovable Cloud?

Lovable Cloud issues no Postgres connection string. Across its Cloud, database, and advanced-settings documentation there is no connection string, no database password, and no service-role key for the backend it runs on your behalf, which is why every pg_dump walkthrough written for a Lovable migration describes a credential you were never given.

Lovable Cloud runs the database so you don’t have to, and the same arrangement is why there’s no connection string to hand you.

This is why third-party exporter tools exist at all. Dreamlit’s open-source Lovable Cloud to Supabase exporter is explicit about its mechanism in its own repository layout, describing an edge function as a “source-project helper function that securely returns source credentials during migration.” It deploys code into your project that reads out the credentials you were never handed, then uses them the way any Postgres migration would.

That can be a reasonable trade, once you know what you’re agreeing to. The thing worth reading first is the helper function’s own source, which an open-source runtime lets you do and a web form does not, and every credential it touched should be treated as exposed once the migration finishes. In the AxonBuild corpus, 6 of 21 third-party apps shipped a real secret somewhere it should never have been, 3 of them permanently in git history, and a migration is the one day a founder pastes every key they own into a new dashboard.

What the Lovable export does not include: storage, edge functions, and secrets

Three excluded items, three separate places to go get them. The full capture sequence, including the order to rotate them in so the new project never runs on a key the old one also holds, sits in what to capture before you hit Remove.

Storage files

They come down from the Cloud tab, bucket by bucket. The export gives you the row that points at an object; the object stays where it is until you fetch it.

Edge function code

It lives in your connected GitHub or GitLab repo if you set one up, and nowhere else if you didn’t, which makes Remove the delete key for your only copy.

Project secrets

Every API key and signing secret in the secrets panel has to come out before removal, and each one should be regenerated at its provider rather than pasted into the new environment unchanged.

Do Supabase auth user passwords survive a migration off Lovable Cloud?

Auth passwords do not survive the export file. Lovable’s documentation states plainly that user passwords are not exported in a usable form and instructs you to plan a password reset flow for migrated users, which means all of your accounts arrive as rows without the one credential that signs them in.

The opposite claim sits on the same search results page, and both can hold at once. A tool that extracts live database credentials and runs a native Postgres copy carries the auth schema across intact, which is why the exporter above advertises a move “without password resets.” The export button’s file is a different path with a different outcome. Either way, one test settles it: restore into a scratch project before cutover, and sign in there as one of your own real accounts using its existing password.

If the answer is a reset, sequence it. Get the reset flow working on the new project before you point any DNS at it, send the email ahead of cutover rather than after the first support ticket, and say why in one sentence. An unannounced forced reset is indistinguishable, from the customer’s side, from the email they would get if you had been breached.

How do I prove a Lovable Cloud to Supabase migration is complete before deleting?

An export is a hypothesis until it has been restored and read. The seven checks below take about thirty minutes on a scratch Supabase project, and they separate “the file downloaded fine” from a Remove button you can press without flinching. Run them while the old project is still alive.

Start with the load. Supabase documents its restore with psql against the destination connection string, and the flags it uses are the ones worth copying: they make a failure loud instead of partial, and they stop foreign keys and triggers from firing while the data goes in.

psql \
  --single-transaction \
  --variable ON_ERROR_STOP=1 \
  --command 'SET session_replication_role = replica' \
  --file your-export.sql \
  --dbname "[CONNECTION_STRING]"

Copy the connection string out of the new project’s dashboard rather than assembling one. Supabase points native Postgres commands at the direct connection, which runs on IPv6 unless the project has the IPv4 add-on, so from an IPv4-only network take the session-mode pooler string instead. Lovable doesn’t publish the export’s file format anywhere I can find, so open what landed before you plan around this command. Then count rows on both sides, per table:

select table_name,
       (xpath('/row/c/text()',
              query_to_xml(format('select count(*) as c from %I.%I', table_schema, table_name),
                           false, true, '')))[1]::text::int as row_count
from information_schema.tables
where table_schema = 'public'
  and table_type = 'BASE TABLE'
order by row_count desc;

Run it on the restored project and compare the output against the same query on the original. A table that arrives with a schema and zero rows looks healthy in a table browser.

1. 01 Row counts per table match between the old project and the restored one, table by table, not in total.
2. 02 Sign in on the new project as one of your own real accounts, using its existing password, before you promise anyone a smooth cutover.
3. 03 Sign in as two separate accounts and try to read each other’s rows through the API. An empty result is the pass.
4. 04 Every SECURITY DEFINER function and every view gets the same two-account test, because neither shows up in a table-level policy review.
5. 05 Every storage object referenced by a row actually resolves on the new project, checked against the buckets you downloaded by hand.
6. 06 Every edge function exists on the new project and returns what it used to, called with a real request rather than read in a file listing.
7. 07 Every secret has a new home and a new value, rotated at the provider rather than copied across.

The third check comes straight out of the audit record. RLS gaps turned up in 9 of 21 third-party apps in the AxonBuild corpus, with 7 of 21 confirmed to let a logged-in user read or write another customer’s data. A policy of that shape travels through a migration looking untouched, because the schema text is intact and the intent behind it was never right to begin with. The version that hides deepest is a SECURITY DEFINER function that trusts a caller-supplied id and bypasses otherwise-correct policies, with no static check noticing.

The concrete form of that test is one request, signed in as user A, asking for user B’s row on the new project:

curl "https://[NEW-PROJECT-REF].supabase.co/rest/v1/orders?id=eq.[USER_B_ROW_ID]" \
  -H "apikey: [PUBLISHABLE_KEY]" \
  -H "Authorization: Bearer [USER_A_ACCESS_TOKEN]"

Supabase enforces row-level security against the Authorization header, so that request runs as user A. An empty array is the answer you want. Anything else is a leak you carried across, now living on infrastructure nobody has ever tested it on. The same standard applies to the file itself: it becomes a Supabase backup you can actually restore once it has been loaded, and not before.

Once all seven pass, Remove is a formality. If two or three sit outside what you can test yourself, that’s the moment to have someone prove the restored project enforces what the old one did, with real accounts against live boundaries instead of a read of the schema. What the move settles is where your data lives. It doesn’t settle whether a Lovable app is safe once it has real users, and the new project starts with no staging environment ahead of its first schema change either.

Common questions about exporting a Lovable database

Does the Lovable Cloud export include storage files and edge functions?

No. Lovable’s documentation states the export does not include files in storage buckets, edge function code, or your project’s secrets. Each one has a different recovery route and a different failure mode: storage is tedious but safe, edge function code is gone for good if no repo was ever connected, and secrets should be regenerated rather than moved. The section above covers all three.

What is the 5 GB limit on the Lovable Cloud export, and what if I’m over it?

Database exports are capped at 5 GB, one per 24 hours, with no partial or chunked export published above the cap. Getting under it means finding the table carrying the bulk, usually an append-only log or a generated-asset table nobody ever pruned, and archiving it out. The other route is a tool that extracts live credentials and runs a native Postgres copy, which the cap does not apply to.

Can I export my Lovable project’s code as well as its database?

Yes, through a separate mechanism. Code portability runs on Git sync to GitHub or GitLab, available on any project at any time. Moving that code to a different host is a frontend move that leaves your backend where it is, so it neither replaces nor requires the database export above.

Do I have to reset every user’s password after leaving Lovable Cloud?

Through the export file, yes: Lovable’s docs say passwords are not exported in a usable form and tell you to plan a reset flow for migrated users. A credential-based migration tool can produce a different answer, so test it against one of your own accounts on the restored project before you promise anything.

Should I check whether the app was production ready before I migrate it?

It’s the cheaper order of operations. A migration carries every existing weakness onto new infrastructure and adds the ones the move introduces, so an app that wasn’t ready before is less ready the morning after. What production readiness means for a Lovable app specifically is worth running first, and it sits inside the larger launch-readiness question that decides more than the hosting does.