How to move a Bolt Database into your own Supabase account
Bolt’s integrated database is convenient. Claiming it moves responsibility for that backend into a Supabase organization you control. This guide is precise about what the documentation says the claim transfers, what it leaves unstated, and what to check the moment it’s done.
What a Bolt Database is
When a Bolt project needs a database, Bolt creates one automatically. Bolt calls it Bolt Database; it’s a Postgres database with sign-in, file storage and server functions built on Supabase, which Bolt names as one of the platforms its cloud is powered by. Before you claim it, the database lives in an organization Bolt controls: you can see and edit it through Bolt’s panels, but you have no Supabase account for it, no dashboard, and no bill of your own. That’s the convenience. It’s also why a Bolt site with a Bolt Database isn’t fully yours even once the code is in your GitHub repository.
What Claim actually does
Bolt’s documentation says claiming your database lets you migrate an existing Bolt database to Supabase, and that afterwards you should see the claimed database appear as a Supabase project in your account. The mechanism behind that is one Supabase documents for platforms generally: a project that lives in the platform’s organization is transferred into an organization of yours, while the platform keeps access to it through an authorized integration. So the claim is an ownership change of the existing project, not a copy into a new one.
In plain English: the database stays where it is and becomes yours. Bolt’s integrated database is convenient; claiming it moves responsibility for that backend into a Supabase organization you control. What Bolt’s documentation doesn’t spell out is what else changes with it, and the next section is honest about that.
What moves, precisely
Because the claim transfers the project rather than exporting from it, the things inside the project are expected to come along. But Bolt’s documentation only specifies the outcome for the database itself. Here is what is documented and what isn’t:
| Piece | After the claim | Basis |
|---|---|---|
| Database structure (schema) | In your Supabase project | Documented: the database appears as a Supabase project in your account. |
| Rows (data) | In your Supabase project | Documented as above; the claim is described as migrating the existing database, not creating an empty one. |
| Auth users | Expected in the project; unverified | Bolt’s sign-in is Supabase-based, and Bolt notes one auth setting changes with your Supabase plan after a claim, but it doesn’t state that users transfer. |
| Storage buckets and files | Unverified | Not mentioned in Bolt’s claim documentation. |
| Server (edge) functions | Unverified | Not mentioned. |
| Secrets | Unverified | Not mentioned. For Supabase-connected projects Bolt says secrets are added in the Supabase project’s Edge Functions settings. |
| Project URL and API keys | Unverified | Not mentioned. Because the project is transferred rather than recreated, they may stay the same; check them. |
| Billing | Unverified, but likely yours | Not stated directly. Bolt says a security setting after the claim depends on whether you’re on Supabase’s free or Pro plan, which implies the project is now on your Supabase plan. |
| Reversibility | Not documented | Bolt states there is no supported flow for moving a Supabase database back into a Bolt Database. |
Treat every “unverified” row as something to check yourself in the Supabase dashboard the moment the claim finishes, rather than something to assume.
Before you click Claim
- I have a Supabase account, and I am an owner of the organization the database will move into. Bolt says this is required and is controlled by Supabase, not Bolt.
- Bolt is connected to that Supabase account; Bolt lists this as the first step.
- I’ve exported every table as CSV or JSON from Bolt’s tables view as a backup, one table at a time, selecting all rows.
- I’ve noted every secret’s name from Database, then Secrets, and know where each is regenerated.
- I know which sign-in methods are enabled and whether the project uses storage buckets or server functions.
- The project is published, so its database isn’t paused; Bolt pauses low-use databases only in unpublished projects.
- I have not connected a different Supabase project to the project. Bolt warns that doing so replaces the connection and may cause data loss, and says to claim instead.
- I understand there’s no documented way back.
The steps
- Connect Bolt to your Supabase account if it isn’t already.
- Open the project with the database you want to claim.
- Click the database icon, then the Advanced tab, then Claim.
- Complete the steps Supabase presents. Supabase’s documented claim flow has you sign in or create an account, choose or create an organization, review the permissions Bolt’s integration will keep, review the transfer details, and confirm.
- Open the Supabase dashboard and confirm the database appears as a project in your organization.
After you claim it
Verify immediately
- The project is listed in my Supabase organization, and I can open its dashboard.
- The tables exist and row counts match my CSV backups.
- Authentication, then Users, lists the site’s users.
- Storage shows the buckets and files the site uses.
- Edge Functions lists the site’s server functions, and their secrets are present; if any are missing, add them under the project’s Edge Functions secrets.
- Settings, API Keys shows the project URL and keys; compare them with the values in the site’s
VITE_SUPABASE_URLand key variables, and update the site if they differ. - The live site still signs in, reads and writes, uploads and pays, tested end to end.
- Supabase’s billing page shows the project on my plan, so I know who now pays and what the limits are.
- Bolt’s Supabase connection shows the claimed database, so Bolt can keep working against it.
- Auth settings: Bolt notes leaked-password protection turns off after a claim on Supabase’s free plan and stays on for Pro; decide whether that matters to you.
If a verification fails, the CSV backups are your record of the data, and the secret names and function code in Bolt are your record of the rest. Nothing in the claim itself deletes the Bolt project.
Can Bolt still work on the site afterwards?
Bolt’s documentation implies yes: it describes the claimed database appearing in Bolt’s Supabase connection dialog and troubleshoots the case where it doesn’t, and Supabase’s claim mechanism is designed so the platform keeps access through its integration. So the expected state is a Bolt project connected to a Supabase project you own, the same arrangement as a project that used your own Supabase from the start. Bolt doesn’t say so in one sentence, which is why it’s on the verification list.
Why CSV exports aren’t the same thing
Bolt lets you export selected rows from a table as CSV or JSON. That’s a copy of data, and it’s worth taking as a backup. It isn’t ownership of the backend. A CSV holds one table’s rows; it doesn’t hold the relationships between tables, the access rules, the user accounts and their credentials, the files in storage, the server functions or the secrets. Exporting tables as CSV is different from claiming: claiming transfers the whole Supabase project into an organization you control, while a CSV copies rows that you would then have to rebuild everything else around. If the claim isn’t available to you, the honest description of what a CSV gives you is “the data, for a rebuild”, and the data guide covers what that rebuild involves.
For everything else about a Bolt site, start with do you actually own your Bolt site? and, when moving, the exit guide.
Sources
The rules and product behaviour described above were checked against these pages when the guide was last updated. If something here has changed, these are the places to look.
- Supabase integration: claim your database · Bolt
- Database: advanced · Bolt
- Bolt Database · Bolt
- Bolt Cloud · Bolt
- Tables: export · Bolt
- Authentication · Bolt
- Secrets · Bolt
- Integration issues · Bolt
- Intro to databases · Bolt
- Supabase for Platforms: claim flow · Supabase
- Access control · Supabase
- API keys · Supabase
- Edge function secrets · Supabase
Keep going
Related guides
Or go back to the overview of what owning your site means, which ties all of these together.
Do you actually own your Bolt site?
What you own when you build with Bolt, and what still depends on Bolt: the code and its GitHub sync, Bolt Hosting, domains bought through Bolt, Bolt Database versus your own Supabase, secrets, and what the documentation says happens when you stop paying. With an ownership checklist.
About a 8 minute read
Where your website’s data lives
Owning the repository is not the same as owning the website. The database, uploaded files, user accounts, form submissions, CMS content and analytics each live in a service with its own owner. How to find every one, work out whose account it’s in, check whether the data can be exported, and record what would have to move.
About a 9 minute read