Running migrations locally and remotely in Supabase - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

What happens when you run supabase db push locally?

You run the command supabase db push on your local machine connected to your Supabase project. What is the expected behavior?

A It deletes all existing migrations and resets the database schema.

B It generates migration files locally but does not apply them to any database.

C It applies all unapplied migrations to the local development database only.

D It applies all unapplied migrations to the remote Supabase database immediately.

💡 Hint

Think about what 'push' means in the context of local development databases.

The supabase db push command applies unapplied migrations to the local development database, allowing you to test schema changes locally before pushing them remotely.

❓ Architecture

intermediate

How should you manage migrations when working with a team on Supabase?

Your team is collaborating on a Supabase project. What is the best practice for managing database migrations to avoid conflicts?

A Only the team lead runs migrations remotely; others do not run migrations locally.

B Each developer runs migrations independently without sharing migration files.

C Delete migration files after applying them to keep the project clean.

D Store migration files in version control and apply migrations sequentially on remote and local databases.

💡 Hint

Think about how version control helps teams coordinate changes.

Storing migration files in version control ensures all team members have the same migration history. Applying migrations sequentially prevents conflicts and keeps databases in sync.

❓ Configuration

advanced

What is the correct way to run migrations on a remote Supabase database?

You want to apply your local migration files to the remote Supabase database. Which command should you use?

A supabase migration up --project-ref <project_ref>

B supabase db reset --remote

C supabase db remote migrate --apply

D supabase db push --remote

💡 Hint

Look for the command that explicitly applies migrations remotely with project reference.

The supabase migration up --project-ref <project_ref> command applies unapplied migrations to the remote database identified by the project reference.

❓ security

advanced

What security risk exists if you run migrations remotely without proper access control?

Consider running migrations on your remote Supabase database without restricting access. What is the main security risk?

A The migrations will run slower due to network latency.

B Unauthorized users could modify the database schema causing data loss or corruption.

C Local migration files might get deleted accidentally.

D The remote database will automatically back up before migration.

💡 Hint

Think about who can run commands on your remote database.

If unauthorized users gain access to run migrations remotely, they can change or delete database structures, risking data integrity and security.

✅ Best Practice

expert

What is the recommended workflow to safely deploy database schema changes in Supabase from local to remote?

Choose the best sequence of steps to safely develop, test, and deploy database schema changes using Supabase migrations.

A Write migration files locally → Run <code>supabase db push</code> locally → Commit migration files → Run <code>supabase migration up --project-ref</code> remotely

B Commit migration files → Run <code>supabase db push</code> locally → Write migration files locally → Run <code>supabase migration up --project-ref</code> remotely

C Run <code>supabase migration up --project-ref</code> remotely → Write migration files locally → Commit migration files → Run <code>supabase db push</code> locally

D Write migration files locally → Run <code>supabase migration up --project-ref</code> remotely → Run <code>supabase db push</code> locally → Commit migration files

💡 Hint

Think about the order of writing, testing locally, committing, then deploying remotely.

The safe workflow is to write migration files locally, apply them to your local database to test, commit the migration files to version control, then apply them to the remote database.