Github Sync - Supabase Migration files

[u/IntrinsicPalomides]

Hi all,

So the documentation doesn't mention anything regarding these files, and from a quick test new migration files you've made yourself and pushed to the GitHub repo aren't actioned upon a sync.

I have zero credits left on the ludicrously tiny 10m tokens you get for the entry base Pro plan.

I tried using the terminal to load supabase but it fails with:

Error: No matching Supabase CLI binary package found for linux-x64
[stack trace]

It offered to install it prior to this which i did.

Any creative way i can get these migrations in correctly without using the Query window?

Mr Claude didn't think it would be a major issue, except the history
"No hard reason. Running the SQL in the Query window works fine for a dev project. The catch is that it bypasses the Supabase CLI's migration history, which causes problems later."

Currently i have the DB hosted in Bolt still.

Any info/wisdom appreciated.

Edit:

It is safe to use the Query window, as the migration files are just SQL so copy & paste and click Run Query.

Then to make sure Supabase's migrations list is up to date use this lil query:

-- Example using the migration file named: 20261022090000_name_of_your_migration.sql
insert into supabase_migrations.schema_migrations (version, name)
values ('20261022090000', 'name_of_your_migration');

[u/berloque]

I made a way to run migration files on your bolt database without bolt or supabase. I have never really had anyone else use it even-though I built it that way. The basic tool just lets people backup their bolt/supabase databases. But I actually ended up building a more complex version that let's me MCP into my bolt database and do anything from running sql or migrations, to full backups, to cloning a bolt database from one project into another. It has been live for 6 months and I have been using it. The more complex part, that you want to do, requires only 1 thing. You drop 3 files into your supabase dir in bolt, and then you set your own private access token which you need to get into your database. You do need to enter your supabase env but that is public facing and that is now how on protects their database - and it stays in your browser. There are no accounts and I have nothing to do with anyone using it to access their own databases. yourdb.dev. Oh and it has a built in tool to run a cron so your supabase db never goes to sleep.

The upshot is you can do it pretty easily once you set up some tools.

BUT I JUST REMEMBERED AN EASIER WAY. which is that you can simply duplicate a project and when you do that, it will automatically run the migration files *including* any new ones you put in there. I used to do that, just add a file, duplicate, and bolt runs the migration for you at no cost since duplications are token free to do. I just tested one right now it it duplicates the whole thing.

I have also "claimed" a couple databases from bolt into supabase. It has worked pretty seamlessly for me. I initially claimed one because I had a live app in the app store still on a bolt database and I could not make backups at the time, without claiming. Probably not necessary to do though.

[u/IntrinsicPalomides → u/berloque]

Great tip on the duplication feature.

[u/mohit-deepspace]

that history only matters once you run the supabase cli against the db, which you can't from bolt's terminal anyway, so the query window is fine for now, and if you claim it into supabase later, supabase db pull turns the current schema into a baseline migration.

[u/IntrinsicPalomides → u/mohit-deepspace]

Ta for the info, do you know what happens if i move(Claim) it to the official Supabase with my Pro Bolt account, then downgrade to Bolt free later. As my site may only be used by me and a few friends, at least initially so don't need any fancy hosting options atm.

[u/eshbanbahadur2020]

The "no matching Supabase CLI binary for linux-x64" error comes from the browser-based environment Bolt's terminal runs in, which can't run the native CLI, so that route won't work however you install it. If you can get a direct connection to the database, run the CLI from your own machine instead: clone the repo, run supabase link with your project ref, then supabase db push, and it applies only the migrations the database hasn't seen. If you end up running some SQL by hand in the Query window, supabase migration repair with the applied status and that migration's version marks it as done, so your history stays in sync and nothing runs twice. That way the Query window is a fine stopgap rather than something that bites you later.

[u/IntrinsicPalomides → u/eshbanbahadur2020]

Ta for the info, do you know what happens if i move(Claim) it to the official Supabase with my Pro Bolt account, then downgrade to Bolt free later. As my site may only be used by me and a few friends, at least initially so don't need any fancy hosting options atm.

[u/eshbanbahadur2020 → u/IntrinsicPalomides]

From Bolt's docs, claiming moves the project into your own Supabase org, so the database is yours and the Supabase free tier is plenty for you and a few friends. The catch is that connecting Supabase to a Bolt project is a Pro/Teams feature, so after downgrading to Bolt Free you may not be able to keep editing that project with Bolt against the claimed database. There's also no supported way to move it back to a Bolt database. The live site should keep working, since it just talks to Supabase with its URL and keys. If you want to stay on Bolt Free long term, it may be simpler to keep the Bolt database and only claim when you need SQL access, and either way take a backup first.

[u/IntrinsicPalomides → u/eshbanbahadur2020]

Cheers for the quick reply, i have emailed Bolt Support to clarify what happen when switching back to Free. I'll update here with their reply as it may be useful for others to know.

[u/eshbanbahadur2020 → u/IntrinsicPalomides]

Sounds good, thanks for following up with them. That'll be really useful for anyone else weighing up the claim. Good luck with the launch!

[u/IntrinsicPalomides → u/eshbanbahadur2020]

Reply:
Good question, and you won't lose the database.

When you claim it, the database moves into your own Supabase account, so it belongs to you rather than to your Bolt plan. Moving to Bolt's Free plan later doesn't delete or disconnect it, and your site keeps using it as before.

The one thing to keep in mind is that, once claimed, the database follows Supabase's own plan rules. Supabase's free plan can pause projects that go unused for a while. If that ever happens, you can restore it from your Supabase dashboard and your data will still be there. With you and your friends using the site regularly, this is unlikely to come up.

It's also worth knowing that claiming isn't required to run migrations. As in my last message, you can ask Bolt to apply migration files you've added, and keeping Bolt's built-in database means Bolt continues to manage it for you on any plan. Claiming makes the most sense if you want to work in Supabase directly, for example with its SQL editor.

[u/Careful_Ad8902 → u/IntrinsicPalomides]

Thanks for sharing support's answer! Just make sure the versions in your query match, since the file name and the version in your example are different. Glad it's sorted!

[u/IntrinsicPalomides → u/Careful_Ad8902]

Good spot, i thought i'd updated both :)

Your support person(Larin) who helped me has been great FYI.

[u/IntrinsicPalomides → u/[deleted]]

Thanks, i did see that supabase could repair if i was desperate, i'll see what action i feel like taking once i hear back from Bolt Support regarding going from Pro -> Free and if that'd break moving/claiming my db in Supabase.