Merge migration files

[psteinroe]

Feature request

Is your feature request related to a problem? Please describe.

After some time, the number of migrations becomes quite large and with it, the startup time. It would be great to have an easy way of merging all existing migration files into a single one that applies the latest state.

Describe the solution you'd like

A single command that that does the actions described above and (maybe optionally) applies the migration to remote(s).

Describe alternatives you've considered

Doing it manually - what is the best way here? It would be great to add it to the tour or the docs.

[noeleom]

+1

[psteinroe]

Any update here? This issue got a few upvotes and I am at 147 migration files now. Would be awesome if someone could provide a best practice.

[soedirgo]

I have an idea on how this might be done, but it's not very well tested - better to try it first on a dev/testing project.

I'll draft up the guide and loop back here.

[Dizotoff]

I think one way to do it would be to

1. Delete supabase_migrations.schema_migrations table content
2. Remove all migration scripts from /migrations/ folder
3. Run supabase db remote commit

Not sure how safe that is.

[soedirgo]

@Dizotoff that's roughly it, yeah. Sorry I'm a bit behind here - might get back to this in a few weeks.

[psteinroe]

with recent updates to the cli the performance of applying migrations is much better. Hence, this issue can be de-prioritized (at least for me).

[bombillazo]

Any update on migration squashing/merging? IWe too are getting to a point we would like to cleanly "reset" the migration history due to all the changes we've made.

[bombillazo]

Hey @psteinroe what recent CLI updates have changed that helped you? We have almost 1 new migration every 2 PRs (we merge pretty constantly) and would like to reduce this in both local and remote deployed projects.

[psteinroe]

Hey @psteinroe what recent CLI updates have changed that helped you? We have almost 1 new migration every 2 PRs (we merge pretty constantly) and would like to reduce this in both local and remote deployed projects.

The change was made a while ago, so you should have it already. It's still not instant. With 300+ files, it takes more time than it should for a decent dev productivity.

I mostly copy the statements I want to debug into the sql editor and execute them there. Not ideal.

But I am sure supabase is working on a better dx for local development.

[bombillazo]

Thanks @sweatybridge! Cant wait to try this out

[bombillazo]

Hey @sweatybridge when I run the squash command with the --linked flag I get the following error:

Squashed local migrations to supabase/migrations/20230620144419_rls-template-files.sql
Baselining migration history to 
Error: glob supabase/migrations/_*.sql: file does not exist

I see a single migration file in the folder.

[sweatybridge]

Thanks for catching the bug. The fix is straightforward and has been released.

[aradhya-variational-io]

👋 Hi! Thanks for adding this feature, would there be a reason a trigger on auth.users would not be included in the squashed migration? It seems that upon running supabase migration squash everything was properly dumped except that trigger 🤔

[joshtune]

👋 Hi! Thanks for adding this feature, would there be a reason a trigger on auth.users would not be included in the squashed migration? It seems that upon running supabase migration squash everything was properly dumped except that trigger 🤔

I noticed the same thing here. It sounds like a security item, which I can understand. It will be hard to trace if I forget to re-include such trigger.

It does make me curious if other triggers get excluded too.

[bombillazo]

This is also happening to us. It seems like the squash logic doesn't take into account that the SB schemas may have been modified by the user and hence not included in the squash.

I had created a ticket to track this : https://github.com/supabase/cli/issues/1562