Lecontodereddit

Fair point! Migration history can be useful when it comes to having a record of changes to the data structure of a specific live environment. But I still don't like mixing those with schema changes - I think of the schema as "what it should look like" vs data operations as "what did we do to production on day X", and it's part of what makes the standard Supabase approach messy and difficult to keep track of. I think my "Launchpad" approach works best during the early to mid stage of a project when theres a lot of iteration and the schema is changing frequently - up to and including the point where there are multiple environments to manage. Once things are more stable and changes become more about data operations, it could make sense to prioritise migration history over this "automatic clean slate ever time" approach. The hybrid idea is interesting - worth thinking about

I just shared this open source tool I built for myself to handle things like this more easily: [https://github.com/krokodillus/Supabase-Launchpad](https://github.com/krokodillus/Supabase-Launchpad) It's a bit opinionated in the sense that it moves completely away from Supabase migration history, but I'm happy to just have a log of the current state of my db schema at various points in time as part of my git history, so the Supabase migration history doesn't really give me anything. It's not perfect but much quicker to deploy and easier to debug. Basically my approach is to keep a clean up to date sql file for tables, functions, triggers, policies etc. as part of my repo, because it makes it very easy to see what the database will look like every time I deploy, easy to troubleshoot and easy to make bulk updates - things are not buried across multiple migration files. Also makes it super easy to just push to whatever environment you want - we have dev, staging, test, demo, then multiple envs for different clients.