Skip to main content
Lovable backs up your project’s database every day. You restore from a backup when data was deleted or a change broke your app. You export when you need a copy of the whole database. This page covers both, and what each one includes.
Backups and exports cover the database only, both structure and data. Files in storage are separate. Download them from More → Storage when you need a complete copy of your app’s data.

Restore a daily backup

To see your backups, go to More → Database, select Manage, then Backups. Each row shows when the backup was taken, in UTC. Lovable takes one backup per day and keeps up to roughly 14 days of them. A backup covers the database only, so a restore does not change the files in storage. The closest restore point is the most recent backup taken before the problem.
Restoring cannot be undone. Any data created or changed after the chosen backup is lost. Because the structure, or schema, is reverted too, your app’s code may not match the restored database if the schema changed after the backup. To keep the current state, export your database first.
Click Restore to this backup on a row and confirm. Lovable rolls the project’s database back to that point, structure and data. The database is unavailable for a few minutes while the restore runs. When the restore finishes, ask Lovable in the project chat to test your app and fix any mismatch between the code and the restored database. Anyone with edit access to the project can restore a backup. On Enterprise plans, every restore is recorded in your workspace audit log. A restore always replaces the same project’s database.

Export your database

Use the export when you need a copy of the whole database, for example to keep your own backup or before you move your backend to another provider. Anyone who can manage the project’s settings can export. The export contains your full database, both structure and data. It also includes your users’ accounts and their password hashes, the scrambled form in which passwords are stored. It does not include files in storage, edge function code, secrets, sign-in provider settings, or your project’s API keys, so plan to move those separately. The export is a compressed PostgreSQL archive that a developer or your new provider’s import tool loads into a new database with pg_restore. For a copy you can open yourself, download a single table as CSV from the Database view instead. See Edit records.
1

Open Database settings

In your project, go to More → Database, select Manage, then Settings.
2

Open the export dialog

In Export project data, click Export data.
3

Start the export

In the Database card, click Export, then click Start export.
4

Download the export

Lovable emails you when the export is ready and saves it to your project’s storage. Download it from More → Storage and keep it somewhere else, because removing the database deletes the export along with the rest of your storage.
Lovable exports databases that use up to 15 GB of storage, and the export file itself can be at most 5 GB. You can request one export every 24 hours. For a larger database, contact support.
You can export only while your database is running. If the project is paused, including when it pauses because your workspace ran out of credits or reached a credit limit, resume it first. See What happens when you run out of credits.

Move your backend to another provider

Lovable does not transfer a project to another backend in one step. To move, export your database, download your storage files from More → Storage, and move your code with Git sync. You set up authentication, secrets, environment variables, and any external services again at the destination. Moving a backend is developer work. If you don’t write code yourself, ask Lovable in the project chat to walk you through the steps, or plan for a developer to help. If you restore the export into a Supabase project, your users keep their passwords. Users who are signed in when you switch need to sign in again, so test that sign-in works after restoring. See Supabase’s guide to migrating users between projects. For a step-by-step walkthrough, see Host backend and data on a managed provider. To connect your own Supabase project to a Lovable project instead, see Supabase. Removing the database deletes your export and your files, so download and verify them first. When the move is done, you can remove the database so the project stops using credits for it.

FAQ

No. A database backup covers the database only, so a restore is not a full recovery of your app.
  • Download your files from storage and keep a copy outside Lovable.
  • Keep your app’s code in version control, such as GitHub.
  • Write down the sign-in configuration you would need to set up again.
Once a day, and Lovable keeps up to roughly 14 days of backups. To see the restore points you have, go to More → Database → Manage → Backups.You can restore any listed daily backup, but not a moment between two of them, and you cannot take a backup on demand from that page. To keep a copy of the current state, export your database. An export does not appear as a restore point.
Yes, with some setup. The export is a compressed PostgreSQL custom-format archive, a .backup file. Load it with pg_restore, not with psql, using PostgreSQL 16 or newer tools, because older ones refuse the compression. Test it in a separate Supabase project you own first.In the new project, set up sign-in providers and API keys again, copy your uploaded files separately, and test sign-in before you move traffic. A restore into plain PostgreSQL can need extra setup for Supabase roles, extensions, and internal schemas. See Move your backend to another provider.
Yes, and it can remove newer ones. A restore replaces your database structure and data with the state of the backup, and user accounts are database data.
  • People who signed up after the backup lose their accounts.
  • Password changes made after the backup are undone.
  • Uploaded files stay in storage, but the records describing them go back too, so files added after the backup stop appearing in your app.
Not reliably. Some of your project’s setup sits outside the tables a restore replaces. Your scheduled jobs are in that group, with the settings they use to call out of the database, and so is your email sending.Contact support before you rely on a restore to bring any of them back.
Not yourself. The Backups page restores an available backup into the same project’s database, and the built-in backend does not give you a direct database connection to load your own dump.If a restore fails, contact support before you make more database changes. Your database is unavailable for a few minutes during a restore, and Lovable does not guarantee how long it takes.
Treat it as a service migration, not a database copy. Plan to move your records, users, files, functions, sign-in settings, and scheduled jobs. See Move your backend to another provider.Create your runtime secrets again in the new project, because a database copy does not carry them. Set up email again too, because a copy of the database does not carry working email sending either.Check each scheduled job’s target and credential before you enable it, and keep the original project until you have tested the new one. Removing the built-in database is a destructive action, not a migration step.