Skip to main content
The Tuturuuu platform uses Supabase migrations to manage database schema changes with version control and reproducibility.

Migration Workflow

Creating Migrations

Method 1: Generate from Studio Changes

Best for: Visual schema editing, quick table creation
  1. Make changes in Supabase Studio:
  2. Generate migration:
  3. Review generated file:

Method 2: Manual SQL Migration

Best for: Complex changes, custom functions, data migrations
  1. Create blank migration:
  2. Edit migration file:

Migration File Structure

Naming Convention

Examples:
Keep new migration timestamps ahead of the latest migration already on main, staging, and production. Supabase refuses to apply a local migration that sorts before the last remote migration unless the operator passes --include-all. Staging and production CI intentionally run supabase db push --include-all so each project can converge after migration history changes, but ordinary forward deploys should still keep timestamps monotonic. After a rebase, merge, or hotfix, re-list apps/database/supabase/migrations and rename any still-unapplied local migration forward instead of treating --include-all as permission to edit or replay old migration history.

File Template

Common Migration Patterns

Creating Tables

Adding Columns

Modifying Columns

Creating Indexes

Creating Functions

Creating Triggers

Creating Enums

Data Migrations

Safe Data Migration Pattern

Batch Processing Large Migrations

Testing Migrations

Local Testing

Test RLS Policies

Verify Indexes

Migration Checklist

Before committing a migration:
  • Migration file has descriptive name
  • All tables have RLS enabled
  • RLS policies are tested
  • Indexes added for foreign keys
  • Indexes added for frequently queried columns
  • Comments added for complex logic
  • Data migration is idempotent
  • Migration tested with bun sb:reset
  • Type generation updated (bun sb:typegen)
  • Breaking changes documented

Deploying Migrations

⚠️ AGENTS: NEVER RUN THESE COMMANDS

Agents should prepare migrations but NEVER deploy them. Only users should run:

Agent Workflow

Agents should:
  1. Create migration file
  2. Test locally with bun sb:reset
  3. Run bun sb:typegen
  4. Commit files
  5. Instruct user to run bun sb:push
Agents should NEVER:
  • Run bun sb:push
  • Run bun sb:linkpush
  • Deploy to production

Rollback Strategy

Simple Rollback

Complex Rollback

Common Issues

Issue: Migration Fails on Production

Cause: Local Supabase version differs from production Solution:

Issue: Type Generation Fails

Cause: Migration has syntax errors Solution:

Issue: RLS Policy Conflicts

Cause: Multiple policies on same table/operation Solution:

Best Practices

✅ DO

  1. Use descriptive names
  2. Add indexes for foreign keys
  3. Enable RLS on all tables
  4. Add comments for clarity
  5. Test migrations locally first
  6. Materialize replacement-table rows before rewiring child foreign keys

❌ DON’T

  1. Don’t skip RLS
  2. Don’t use DROP without backup
  3. Don’t modify old migrations
  4. Don’t deploy without testing

External Resources