How to Export Your Data from Bolt Database

Your code is the easy part of leaving Bolt. Your data is the part customers notice. This guide covers how to move what’s in Bolt Database into a database you own without losing a row.

This is Step 4 of the full Bolt migration guide.

What’s in Bolt Database

Bolt Cloud gives each project a managed database with built-in authentication, file storage, logs, secrets, security audits, server functions and user management. Your code reaches it through environment variables in the project. The ZIP or GitHub export includes the code that talks to the database, but not the database.

One detail to know before you start: Bolt’s docs state that Version History doesn’t support database restores. Rolling back a project changes code, not data. Take your own backup before any risky change.

Option A: Claim the database into Supabase

From the Advanced settings, Bolt can transfer the database into your own Supabase organization. After the claim, it’s an ordinary Supabase project that you administer, with your own billing, backups and dashboard.

Good for: teams happy to stay on Supabase, or who want a stepping stone before moving to plain Postgres.

Check before you rely on it:

• You must be an owner of the target Supabase organization.
• Confirm whether auth users and their password hashes come across.
• Confirm whether storage bucket files come across, or only bucket definitions.

Run the claim on a copy or a test project first if you can.

Option B: Export tables as CSV or JSON

Export each table one at a time. Then:

1. Recreate the schema in your target database: columns, types, primary keys, foreign keys and indexes.
2. Load the tables parents first, children second, so foreign keys resolve.
3. Recreate row-level security policies, or the equivalent checks in your API.

JSON keeps nested fields and arrays intact. Use it for any table with structured columns.

Users and passwords

If password hashes move with your users, they sign in as before. If they don’t, plan a friendly re-entry:

• Import users with their IDs, emails and roles.
• Send a branded “we’ve moved” email with a magic link or password-reset link.
• Keep the old IDs, so everything the user owns stays linked to them.

Storage files

Download every object from each bucket, upload it to your storage (S3, Cloudflare R2 or Supabase Storage), and rewrite any file URLs saved in your tables. A simple mapping table of old URL → new URL makes this safe to re-run.

Prove nothing went missing

Before cutover, reconcile:

Check	How
Row counts	Compare every table, old vs. new
Spot checks	Open ten random records per table in both apps
Relationships	Query for orphaned foreign keys
Files	Count objects per bucket, then open a sample
Users	Sign in with test accounts of every role

Do the final export during a short write freeze so nothing changes between the last sync and the DNS switch.