SnapbackSupabase migration safety: catch bad database changes earlier
A migration can be syntactically valid and still change more data than intended. Safety comes from making the before-and-after state visible.
Before the migration
Confirm the target database, review the SQL, and make sure you have a recovery path. Supabase's CLI documentation covers logical backup and restore workflows when you need a portable export.
For a review tool, use a dedicated read-only role rather than a service_role key. The connection should be able to inspect the database without being able to modify it.
grant usage on schema public to snapback_ro;
grant select on all tables in schema public to snapback_ro;After the migration
Compare the latest snapshots and look for unexpected table, column, and row changes. Pay special attention to deletes, primary-key changes, and large row-count jumps.
If a table exceeds the review tool's limits or cannot be read, treat that as an explicit gap in the review—not as proof that nothing changed.
Keep the decision with the operator
A diff is evidence, not an automatic rollback. Validate the intended result, communicate the impact, and use your established migration or restore process for any write operation.
Snapback beta and free accounts remain read-only. They can help locate the blast radius without taking write access to your database.