Change your Bolt.new database safely: migrations, not edits

To change the database of a Bolt.new app safely, make every change as a written SQL migration that you review before it runs and keep with the code, instead of asking for quick edits in chat or clicking through the table editor. Back up the data first, prefer changes that only add things, delay anything that renames or deletes until the code no longer depends on it, and check the app afterwards. Restoring an earlier version in Bolt doesn't undo database changes, so the database needs its own safety net.

This guide explains why ad-hoc changes cause trouble, which changes are safe and which are risky, a step-by-step routine inside Bolt and how to do the same with the Supabase CLI once the app has real users.

Why are quick database edits risky?

When you prompt "add a status to orders", the agent changes the live database and the code in one go. That's fine for a prototype. Once people use the app, it creates problems:

• Code and database can drift apart. Bolt's version history restores files, not tables. Its documentation says plainly that restoring an earlier version won't change your Bolt or Supabase database. Roll back the code after a schema change and the app may now ask for columns that look different.
• There's no record of what changed. Without a migration file, nobody can tell later why a column exists or what it replaced.
• The agent may take the short path. Asked to "fix" a table, an AI can drop and recreate it, which deletes its rows.
• There's often only one database. In many Bolt projects the preview and the live site share it, so a mistake while testing hits real customers.

What is a migration?

A migration is a SQL file that describes one change, has a timestamp in its name and is applied once, in order. With the Supabase CLI, they live in supabase/migrations/ with names like 20261020143000_add_order_status.sql, and the database keeps track of which ones have been applied. Open Code view and check whether your project already has this folder; if the agent has been writing SQL files there, they're your change history so far.

The value is simple: every change is visible, reviewable, repeatable on another database and kept in GitHub with the code that needs it.

Which changes are safe and which are risky?

Renaming without breaking anything

Do risky changes in stages, often called expand and contract:

-- 1. Expand: add the new column next to the old one
alter table public.orders add column if not exists status text;

-- 2. Copy existing data across
update public.orders set status = state where status is null;

Then update the code to read and write status, publish, and check it works. Only in a later migration, once nothing uses state, drop it:

alter table public.orders drop column state;

How do I change the database safely in Bolt?

1. Ask for the SQL first, without running it. In Plan mode: Write the SQL migration for adding a status column to orders as a new file in supabase/migrations. Don't run it, and don't drop, rename or recreate any table.
2. Back up the data. In the database settings, open each affected table, select all rows and choose Export (CSV or JSON). Download the project too. Bolt's Tables documentation describes the export.
3. Read the SQL before it runs. Look for drop, truncate, delete without a where, alter ... type and rename. If one appears and you didn't ask for it, stop and ask why.
4. Apply it. Let Bolt run the migration, or paste it into the SQL editor (Query in the Tables view).
5. Verify. Check the table's columns and a few rows, open the Security tab and confirm any new table has RLS on, then run through the main flows of the app.
6. Bookmark the version in version history, so you know which code matches this database shape.

New tables deserve a special mention. Bolt's security documentation says Bolt turns on RLS for the tables it creates, but tables you add yourself need it too. A table without RLS can be read and changed by anyone with your public key, so include alter table ... enable row level security; and the policies in the same migration.

What changes when the app has real users?

At that point it's worth moving the database under your own control. On Pro and Teams plans, Bolt lets you claim a Bolt database into your own Supabase account. Then you can use the Supabase CLI and a separate test project:

supabase link --project-ref <project-ref>
supabase db pull                         # capture the current schema
supabase migration new add_order_status  # create an empty migration file
supabase db push                         # apply pending migrations
supabase migration list                  # compare local and remote

Run each migration against a staging project first, then production. Our guides to Supabase migrations with the CLI and a staging environment for a small app cover the setup, and Supabase backups explained covers what your plan keeps for you.

Quick answers

Can I undo a migration with Bolt's version history? No. Version history restores code only. To undo a schema change, write a new migration that reverses it, and restore data from your export if needed.

Is it OK to edit tables in the table editor? For data, yes. For structure, use a migration so the change is recorded and repeatable.

Why did a column disappear after a prompt? The agent likely recreated the table or renamed the column. Check the migration files or the chat for drop or rename, then restore from your export.

Do I need migrations for a prototype with no users? Less, but the habit costs little, and it pays off the first time someone signs up.

Planning a change you can't afford to get wrong?

If your app already holds customer data, a second check before a schema change is cheap insurance. Our Supabase security review covers schema, policies and backups, and Bolt app rescue handles migrations as fixed-price fixes. Begin with the free health check, or tell us what you need to change. If an earlier change already broke something, see when Bolt breaks the app with every change.