The local development & database migration story is Supabase's biggest weakness. I hate having to do migrations live in prod. The admin dashboard is just so much better than any alternative Postgres tooling that it's been worth using despite that. Takes care of the stuff I'd normally be sweating over when writing migrations like nullable fields / FK constraints / JSON formatting for default fields. Would be great if Supabase allowed for a "speculative migration" in its UX where it spit out a file you could use locally to test beforehand.
Please don't use the Dashboard to edit your database in production. We're working on Preview Databases which will help enforce this. For now this fits into our Shared Responsibility Model:
You are responsible for a workflow that's suitable for your application. Once you get into production, you should be using Migrations for every database change. I have a more thorough response here: https://news.ycombinator.com/item?id=36006018
> Please don't use the Dashboard to edit your database in production.
You should make the default editor read only and allow switching to write mode with a big warning. This would discourage people from writing SQL or using UI to modify in production.
The dashboard has always screamed "use me to edit" and I have used supabase in the beginning and very recently too. Nothing has changed to discourage it so far.
Maybe something like mode button which is present at top and you can click to switch between development and production mode?
This would also change a couple more things which you do not want to touch in production by accident.
If you use the CLI, `supabase start` spins up a Docker instance built from all your migration .sql files [1].
If anything, I think the admin dashboard encouraging directly doing operations on the database is the biggest weakness of Supabase. I would much prefer being able to lock it down to purely CI-driven migrations.
