Laravel Migrations — Drop Table Blocked by FK Constraint

Your database schema is living, breathing code. It changes with every new feature, every pivot, every stakeholder request that comes in on a Friday afternoon. Without a disciplined system to track those changes, you end up with the classic nightmare: a production database that looks nothing like your local one, a colleague who manually added a column nobody else has, and a deploy that breaks spectacularly because a table column your code expects simply doesn't exist on the server. Laravel migrations exist to make that chaos impossible.

The problem they solve is deceptively simple: how do you keep database structure changes in sync across every environment — local, staging, production — and across every developer on a team? Raw SQL scripts dumped into a shared folder don't cut it. You need version control for your schema, with the ability to move forward and backward through changes, the same way Git lets you move through code commits. Migrations give you exactly that, built directly into the framework with a clean, expressive API.

By the end of this article you'll know how to design thoughtful migrations for real features, understand the difference between up() and down() and why down() is more important than most developers think, handle foreign keys and indexes correctly, avoid the three mistakes that bite intermediate developers, and feel confident talking about migrations in a technical interview.

How Migrations Work Under the Hood — The migrations Table Explained

When you run php artisan migrate for the very first time, Laravel does something before it touches any of your own migrations: it creates a table called migrations in your database. This table has two important columns — migration (the filename, minus the .php extension) and batch (an integer that groups migrations run together into one batch).

Every time you run migrate, Laravel reads the migrations table, compares it against the migration files in your database/migrations folder, and runs only the files it hasn't seen before. That's the entire tracking mechanism — dead simple, brutally effective.

The batch number is the key to rollbacks. When you run php artisan migrate:rollback, Laravel finds the highest batch number in the table and calls down() on every migration in that batch — in reverse order. So if you migrated three files in one migrate call, a single rollback undoes all three. Understanding this batch concept is what separates developers who use migrations correctly from those who accidentally roll back changes they didn't mean to.

This also means migrations are environment-agnostic. You run the exact same commands on local, CI, and production. The migrations table on each machine tracks its own state independently.

Writing Migrations for Real Features — Foreign Keys, Indexes, and Column Modifiers

A create migration is just the beginning. Real applications constantly need to modify existing tables — adding columns, creating relationships, dropping obsolete fields. These are alter migrations, and they're where most intermediate developers make mistakes.

Foreign keys deserve special attention. Laravel's foreignId() method creates the column AND the index in one call. But you still need to call constrained() if you want the actual foreign key constraint at the database level. Without constrained(), you just have an integer column — no enforcement. The database will happily let you insert a user_id that points to a user who doesn't exist.

Indexes are equally important and equally overlooked. Every column you filter by in a WHERE clause or join on should have an index. Adding ->index() to a column in your migration is the right time to think about this — not after your queries start timing out in production with 500,000 rows.

Column modifiers like ->nullable(), ->default(), ->after(), and ->unsigned() are how you express business rules at the schema level. A price column should always be ->unsigned(). A deleted_at column for soft deletes should always be ->nullable(). These aren't just database hygiene — they're guards against bad data entering your system.

Rollbacks, Refresh, and the Seeder Workflow — Keeping Your Dev Loop Fast

Here's where migrations become genuinely powerful as a development tool, not just a deployment mechanism. The trio of migrate:rollback, migrate:refresh, and migrate:fresh are commands every intermediate developer should have muscle memory for — but each does something distinct.

migrate:rollback undoes the last batch only. It's surgical. Use it when you realise a migration you just ran has a mistake and you want to fix it before pushing.

migrate:refresh rolls back ALL migrations, then re-runs them all from scratch. It also accepts a --seed flag, which runs your database seeders after migrating. This is the command you run when you want a clean but fully-seeded local database — perfect at the start of a work session.

migrate:fresh is more aggressive. It drops every table (using DROP TABLE, not your down() methods) and re-runs all migrations. It's faster than refresh because it skips the rollback logic, but it means your down() methods are never tested. That's why you should run migrate:refresh occasionally — it proves your down() implementations actually work.

The --pretend flag on migrate is an underused gem: it prints the raw SQL that would be executed without actually running it. Essential for auditing migrations before they touch a production database.

Squashing Migrations and Multi-Environment Deployment — Production-Grade Patterns

After a year of active development, a project might have 80–120 migration files. Running them all on a fresh CI environment takes time, and the sheer number of files makes the database/migrations folder intimidating. Laravel's schema:dump command solves this.

php artisan schema:dump exports your current database schema as a raw SQL file stored in database/schema/. On future migrate runs, Laravel loads that SQL dump first (getting you to the current state instantly), then runs any migrations created after the dump. You get the speed of a single SQL file combined with the precision of individual migration files for recent changes.

For production deployments, the golden rule is: migrate goes in your deploy pipeline, not migrate:fresh. You'd never drop all tables on production. Most teams run php artisan migrate --force in their CI/CD pipeline — the --force flag bypasses the confirmation prompt that Laravel shows when it detects you're running in a production environment.

If your application has significant traffic, consider running migrations during a maintenance window and checking for zero-downtime migration patterns: adding columns as nullable first, backfilling data in a separate job, then adding constraints in a third migration. This approach prevents table locks from taking your app offline mid-deploy.

Testing Migrations and CI Integration

Treat migration files as executable code — because they are. That means they need tests, just like your controllers or services. A migration that works on your local MySQL may fail on the production MariaDB, or a down() method that looks correct might crash on rollback because of a subtle constraint difference.

The most reliable way to test migrations is to run them as part of your CI pipeline on a fresh database before every deployment. Use php artisan migrate:fresh --seed in a CI job that targets a temporary database (or an isolated schema). This catches three categories of failure:

• Symmetric failures: down() doesn't reverse up() — the refresh step detects this.
• Environment drift: migrations that rely on a specific MySQL version or extension fail in CI's database.
• Data compatibility: the seeded data validates that column defaults, constraints, and foreign keys actually work with realistic data.

You can also write unit tests using the RefreshDatabase trait, which rolls back all migrations after each test. This is slower but ensures each test starts from a known state. However, for migration integrity, a dedicated CI step that runs migrate:fresh from scratch is more reliable.

Frequently Asked Questions