Database export formats across AI app builders: what you can actually take with you

You built an app on Lovable, Bolt, or Base44, and now you want your data out. Maybe you’re moving hosts, maybe you just want a backup you control. The question nobody answers up front: what format do you actually get, and can you restore it somewhere else? The answer decides how painful the move is.

Why the format is the whole game

There’s a big difference between “I can see my data” and “I can rebuild my database somewhere else.” Three formats show up across AI builders, and they’re not equal:

• A full SQL dump (like pg_dump output). This is the good one. It includes your tables, columns, types, indexes, constraints, and rows. You can load it into any Postgres and get an exact copy. This is a real backup.
• A schema-less data export (CSV or JSON per table). You get the rows but lose the structure: foreign keys, types, indexes, defaults. You can read it, but rebuilding a working database from it is manual work.
• A UI download only. Some platforms let you export a table to CSV from a dashboard, one table at a time, with no way to script it. Fine for a spreadsheet, useless as a backup strategy.

The rule of thumb: if you can’t produce a file that restores into a fresh Postgres with one command, you don’t really have a portable backup. You have a copy of the contents.

What each builder gives you

This shifts as platforms update, so check your own dashboard before you rely on it. As a general map:

Builder	What’s underneath	Export you get	Restores elsewhere cleanly?
Lovable (Supabase)	Postgres via Supabase	Full connection string, pg_dump access	Yes, it’s real Postgres
Bolt	Varies by chosen backend	Depends on backend wired in	Only if backend is standard Postgres
Base44	Managed backend	Dashboard export, often CSV/JSON	Partial, schema needs rebuilding
Framer	No real database	Form/CMS content export	No, not a database to begin with
Firebase-based apps	Firestore (NoSQL)	JSON export	No, it’s a different data model

The pattern: builders sitting on standard Postgres (Supabase under Lovable) give you a clean exit. Builders with their own managed backend give you your rows but make you rebuild the structure. NoSQL backends like Firestore give you JSON that doesn’t map onto Postgres at all without a migration step.

The trap with CSV and JSON exports

A CSV export feels reassuring. You open it, all your data’s there, you relax. Then you try to restore it and hit the wall: CSV doesn’t store which column is a foreign key, which one auto-increments, what the date format is, or how tables relate. A ten-table app with relationships becomes a weekend of manual schema reconstruction and careful import ordering.

JSON is a little better because it can nest related data, but it still doesn’t carry the database structure. You’re recreating the schema by hand and hoping you got the types right.

Neither is a disaster if it’s all you can get. Just don’t mistake it for a backup you can restore under pressure. Test the restore before you need it, not during an outage. We wrote a full walkthrough of that in the backup and restore tutorial.

How to get the best export your builder allows

Whatever platform you’re on, the goal is the same: end up with a file you can restore into a fresh Postgres without the original platform’s help. Here’s the order to try, best to worst:

1. Look for a direct database connection string. Settings, environment variables, or a “database” tab. If you find a postgres:// URL, you’ve got full access. Run pg_dump "your-connection-string" > backup.sql and you have a real, complete, restorable backup. Store it somewhere you control, not just on the platform.
2. Check for a built-in dashboard export. Some builders offer a one-click “export database” that produces a SQL file. Use it if that’s the best available, and check whether it includes schema or just rows.
3. Fall back to per-table CSV or JSON. If that’s all there is, export every table, and also write down the schema by hand: column types, relationships, and which columns are keys. That note is what turns a pile of CSVs back into a working database later.

Run whichever of these you can this week, not the week you need it. An export you’ve never tested is a guess. Load it into a throwaway Postgres and confirm your data comes back before you count on it.

Why this matters more for AI-built apps

Apps built with AI tools tend to grow features fast and documentation slowly. Six months in, you often don’t fully remember how the database is wired, because a tool generated a lot of it. That’s exactly when a clean, restorable export matters most, and exactly when a pile of schema-less CSVs hurts most.

There’s also the lock-in angle. Builders make money keeping you on their platform, and a hard-to-export database is one way that happens, whether by design or just neglect. Knowing your export options up front tells you how free you actually are to leave. If the honest answer is “I can see my data but I can’t really take it,” treat that as a risk to fix before you’re bigger and more stuck. We go deeper on that in the vendor lock-in post.

Or, we do it for you

If you’re not sure what you can actually export from your builder, we’ll check it for you and tell you straight. Book a free audit and we’ll map exactly what’s portable and what’s locked in.

FAQ

How do I know if my app uses real Postgres?

Look for a connection string in your platform settings, usually starting with postgres:// or postgresql://. If you can paste that into a Postgres client and see your tables, you’re on real Postgres and can run pg_dump for a full export. Lovable apps on Supabase work this way.

Is a CSV export good enough for a backup?

For a single table you want in a spreadsheet, sure. For protecting a live app with related tables, no. CSV loses your schema, so restoring it means rebuilding structure by hand. Get a full SQL dump if the platform allows it.

Can I convert a Firestore JSON export to Postgres?

Yes, but it’s a migration, not a restore. Firestore is a document database with a different data model, so you’re designing a Postgres schema and writing a script to map documents into rows. It’s doable and worth it if you’re moving off Firestore, just budget real time for it.

What’s the safest export to ask for?

A full SQL dump from pg_dump, stored somewhere you control. It captures schema and data together and restores into any Postgres with one command. If your builder can’t produce one, that’s a lock-in signal worth taking seriously.