Which is better for production schema changes, editing directly in Studio or CLI-managed migrations, and why?

For anything beyond a quick, one-off inspection or an emergency fix, CLI-managed migrations are the better choice for production, because they turn a schema change into an artifact that can be reviewed, tested against a preview branch, and applied identically and repeatably across every environment — the same properties that make version-controlled application code safer than editing files directly on a production server.

Editing directly in Studio's SQL editor against production has a real place: diagnosing an incident with read queries, or a genuinely urgent one-line fix when going through a full PR-and-CI cycle would take too long relative to the cost of continued downtime. Even then, the discipline that keeps this safe is treating it as an exception rather than the norm — retroactively capturing whatever was changed as a proper migration file afterward, so the change isn't silently lost the next time someone runs supabase db push against a fresh environment or a teammate wonders why staging and production have quietly diverged.

The honest answer, then, is CLI-managed migrations as the default and Studio edits as a deliberate, logged exception — not a permanent alternative workflow running alongside it.