Supabase: try a schema change before bringing it to production
Supabase provides a Postgres-based application backend with APIs, authentication and file storage. Branches let teams try schema changes in a separate environment, test their application and review migrations before merging.
Form your own approach first, then explore the reasoning to check trade-offs and validation you may have missed. There is no single right answer.
What must a schema-merge confirmation make clear?
Scenario
Design a confirmation page for merging a preview schema into production in your own database-management tool. A photography studio needs to add session duration to bookings. This is an invented product exercise, not a recreation of Supabase; no SQL execution is required.
Known conditions
- The preview branch was created from production schema V1. It holds only schema and manually created test records, with no real customer bookings. A schema diff does not merge the two sets of data records.
- The preview adds a required integer duration_minutes column and deletes the old notes column. Production has 800 historical bookings. No duration backfill plan has been supplied, and nobody has confirmed whether support staff still use notes.
- After the page generates its diff, a colleague upgrades production to V2 with a new booking-time constraint. The diff and confirmation based on V1 are now stale.
- The system can provide production and preview versions, a diff and check records. The page helps people understand consequences and confirm the right version. You need not design cross-database transactions or promise automatic reversal of executed changes.
Deliverables and walkthrough
Sketch three states: first review, production-version change, and completed checks. Identify the two unanswered business questions, which actions must remain unavailable, and how to explain the need to regenerate the diff. Use two observation tasks to check whether people confuse “the test database can save” with “800 historical records can migrate.” Do not invent actual test results.
Explore the reasoning
- Put the target and versions before the decision. Show preview origin V1, current production V2 and the actual merge destination. Separate schema changes from data records so people do not assume test records will fill gaps in production.
- Translate operations into business questions. Required duration needs backfill and old-client compatibility checks. Deleting notes needs confirmation of its support use and retention. Two green diff lines and one overall checkbox are insufficient.
- Invalidate stale confirmation. Retain the old preview for comparison, but require a regenerated diff, conflict handling and checks. A new diff cannot reuse an old authorization. This is a design requirement, not an assumption about an existing backend protocol.
- Attach evidence to each change. Show sample provenance, historical-record tests, dependency checks and unfinished items. Say what remains unresolved instead of treating preview success as proof of the whole migration.
- Observe consequence understanding. Present a passing empty-database test and changed production version. Ask what happens next and why. Check recognition of backfill, deletion dependencies and confirmation version, rather than counting clicks.