Supabase is great for getting started quickly and for most projects I've found it easy to scale with too. But Supabase's migration approach has never really worked for me. Instead of having a "single source of truth" in your files, like with other code, the current state of the database ends up spread across multiple migration files - many of them containing changes that have later been reversed too. Adding a column means writing a migration, hoping it doesn't conflict, then deploying it, then the other environments might need a slightly different migration because they were in a different state, so everything becomes a pain to keep track of.
So I built a small tool that I've been using myself for a while that replaces migration history with a single current-state schema. You keep SQL files that describe your tables as they are right now. Want to add a column? Just add it to the CREATE TABLE in the SQL file. When you deploy, the tool diffs your local schema against the remote db and generates the exact SQL needed. This makes it straightforward to deploy to new instances or push updates across dev, staging, prod, client 1, client 2, etc. Every deployment syncs back to the local files, so environments don't drift.
It won't be the right approach for everyone, but if you've been frustrated by migration conflicts, the pain of managing multiple environments, or just want a single file that describes what your tables actually look like, it might be worth a look.
There might be stuff I haven't thought about, or I might even be completely wrong to take this approach - but thought I'd share it here in case any of you might find it useful, or have any other perspectives on how to handle this: https://github.com/krokodillus/Supabase-Launchpad
Lecontodereddit discusses challenges with Supabase's migration approach, proposing a tool that uses a single current-state schema instead of multiple migration files. This tool helps manage multiple environments by syncing local schema changes with the remote database. db_Forge suggests a hybrid approach to retain migration history for complex changes. Lecontodereddit acknowledges the value of migration history for stable projects and considers the hybrid idea.
I get why this feels cleaner, but I’d be nervous about losing the “how did we get here?” part for anything beyond simple schema changes. Current-state SQL is nice for fresh environments, but once real data, backfills, destructive changes, and one-off fixes enter the chat, migration history usually stops being bureaucracy and starts being evidence. A hybrid approach might be the sweet spot: periodically squash into a new baseline, then keep forward migrations from there.
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
No astroturfing or synthetic engagement. Posts and comments must reflect genuine human engagement. Content that exists primarily to manipulate sentiment, simulate community activity, or feed AI training pipelines will be removed.