How to export your Supabase database from a Lovable app

July 29, 2026

If you built on Lovable and now want your data somewhere you control, the good news is that there is no proprietary lock on the format. Supabase is Postgres. A Postgres database can be dumped, moved and restored with tools that have existed for decades.

The bad news is that “the database” is not the same thing as “everything your app needs to work”, and the gap between those two is where migrations quietly fail.

What you need before you start

Access to the Supabase project behind your app, and from it the database connection details. If the Supabase project was created for you and you have never opened it directly, sort that out first — everything below assumes you can connect.

You also want pg_dump and psql available locally. Match the major version to your database where you can; a newer pg_dump reading an older server is usually fine, the reverse often is not.

Take the dump

A plain SQL dump of schema and data:

pg_dump "postgresql://USER:PASSWORD@HOST:PORT/postgres" \
  --no-owner --no-privileges \
  --file=backup.sql

--no-owner and --no-privileges matter more than they look. A dump taken with ownership intact will try to assign objects to roles that do not exist on your new server, and the restore fails in a confusing way on the first statement.

If you only care about your own tables and not the platform’s internals, restrict it:

pg_dump "postgresql://..." \
  --no-owner --no-privileges \
  --schema=public \
  --file=public-only.sql

Be deliberate about that choice. Restricting to public gives you a clean file — and drops your users, because authentication data does not live there.

What the dump does not contain

This is the part worth reading twice.

Uploaded files. Object storage is a separate system. Images, avatars, attachments and exports are not in your SQL file. The app will come back up looking healthy and every uploaded file will be a broken link. These have to be copied separately.

Secrets and environment variables. API keys for payments, email, and any third-party service were configured in a dashboard, not committed to your repository. Inventory them before you cut over. Discovering a missing key because customer receipts stopped sending is an expensive way to find out.

Server-side functions. Anything running as an edge function runs on the vendor’s runtime. The code may be in your repository; the thing that executes it is not, and it needs a new home.

Scheduled jobs. Cron-style tasks configured through the platform do not travel in a dump. Write them down.

The part that decides whether cutover hurts

Your users’ credentials.

Password hashes live in the authentication schema, not in public. If you dump only public, you have exported your application data and left every account behind — and you will not notice until nobody can log in.

If you are moving to a self-hosted Supabase, keep the authentication schema in the dump and it comes across intact. If you are moving to a different auth system entirely, check whether it can accept the existing hash format before you commit to the plan. When it cannot, the honest options are a forced password reset for everyone, or a different target system. Both are workable. Discovering the problem on cutover day is not.

Verify before you trust it

A dump you have never restored is a file, not a backup. Spin up a throwaway Postgres, restore into it, and check:

psql "postgresql://USER:PASSWORD@LOCALHOST:5432/verify" --file=backup.sql

Then actually look:

Row counts on your three or four most important tables match the source
Row-level security policies came across, if you rely on them
The newest rows are there — confirming you dumped after the last writes
Foreign keys and indexes exist, not just tables

Only once that passes have you got something worth planning a migration around.

Where this leads

Exporting is step one of four. The database has to land somewhere, the front end needs a host, storage needs copying, and DNS has to move last. If you want the shape of the whole job, that is written up in how to move a Lovable app to your own server.

And if you would rather not spend a weekend on it, that is what we do.