How to back up a Supabase project built with Lovable

There are two different answers, and which one applies to you depends on a choice you may not remember making. Lovable apps run on one of two backends: Lovable Cloud — the built-in backend, which uses Supabase’s open-source foundation under the hood — or a Supabase project you connected yourself. The first gives you export paths but not the Supabase project. The second is a normal Supabase project, and everything about backing up Supabase applies to it directly.

First: which mode are you in?

Check the project itself, not your memory — on a team, whoever connected Supabase may not have been you. If your Lovable project’s settings show a connected Supabase project, you are in connected mode: a real Supabase project sits behind the app, with a dashboard its owner can open. If the backend was enabled inside Lovable and no Supabase project is connected, you are on Lovable Cloud — a database section inside Lovable, no Supabase dashboard anywhere. That difference decides everything below.

Connected Supabase: your project, your backups

Lovable’s own docs draw the line cleanly: with a connected project, infrastructure — backups included — is managed by you in Supabase. Lovable deploys code and edge functions; the database is yours. So the standard Supabase backup rules apply, starting with the one that surprises people: the Free plan has no automated backups, and plenty of Lovable projects sit on free-tier Supabase.

The fixes are the same as for any Supabase project, in ascending order of effort-once-set-up: a one-off pg_dump right now, a scheduled GitHub Actions workflow (fifteen minutes; free at side-project scale — the guide covers the egress math), or a hosted service that backs up to a bucket you own and restore-tests the result. One Lovable-specific note: apps built by prompting tend to lean hard on Storage for user uploads — database backups do not include those files, whoever takes them.

Lovable Cloud: export paths, honestly assessed

On Cloud, the Supabase project underneath is not yours. You work through Lovable’s Database section — table view, SQL editor, backups — rather than the Supabase dashboard, and external backup tools (ours included) have no project to connect to. What Cloud does give you has a defined contract: a daily backup of the database, retained for roughly 14 days, restorable in place — restores are permanent, so anything written after the chosen snapshot is lost. And the backups cover the database only; files in storage buckets are not in them.

For a copy you actually hold, Cloud offers a database export — full structure and data, capped at 5 GB, one export per 24 hours. Know its edges before trusting it: Storage files, edge function code, and secrets are not in it, and user passwords are not exported in a usable form, so any migration needs a password reset flow. Treat the export as your database backup — run it on a calendar rather than a feeling, and when it completes, download it and move the copy off Lovable: an export left sitting inside the project disappears with it. Storage files ride separately — the Storage view lets you select files and download them as a zip archive; tedious, but do it whenever you export, because nothing else covers them.

If the app has graduated — real users, real data — plan the move to a connected Supabase project sooner rather than later: there is no one-click migration from Cloud, so the export-and-rebuild only gets bigger as the data grows.

If you are choosing today

Cloud is genuinely the right default for prototypes; zero backend setup is the whole point of building this way. The moment the data would hurt to lose, connect your own Supabase project instead: you get the dashboard, the connection string, backups you control, and the ability to point any backup tool at it — plus you skip the export-and-rebuild migration entirely. Ownership is cheap on day one and expensive to retrofit.

FAQ