Deploy and Version-Control Database Schema Migrations
The Global Administrator oversees the database schema lifecycle for all application tables (users, organizations, activities, assignments, etc.). All schema changes must be expressed as Supabase migration files under version control. The admin must be able to apply migrations to each environment in order, verify migration status, and roll back if necessary. This covers the full blueprint schema including 60+ tables.
User Story
Acceptance Criteria
- Given a new migration file is added to /supabase/migrations, when the admin runs supabase db push, then the migration is applied to the target environment and recorded in the migrations table
- Given multiple pending migrations exist, when the admin deploys, then migrations are applied in sequential order without skipping or reordering
- Given a migration fails midway, when the admin checks migration status, then the failed migration is clearly identified and the database remains in its pre-migration state
- Given the admin queries migration history, when viewing the supabase migrations table, then all applied migrations show timestamps, checksums, and success status
- Given a new organization is being onboarded, when the admin provisions their database context, then the full schema is available with all RLS policies active
Business Value
Schema version control is critical for a multi-organization platform. Without it, schema drift between environments causes data integrity failures, broken API responses, and potential data loss. For a platform handling sensitive health and financial data across NHF, Blindeforbundet, and HLF, schema consistency is a compliance requirement.
Components
- Database Schema data
- Supabase Platform infrastructure