Why reach for the DB facade in a migration?

Migrations aren’t only for schema changes. Sometimes a migration also needs to reshape existing data, like backfilling a newly-created column or renaming a value across every row.

When you touch data in a migration, you have a choice: use the Eloquent model or use the DB facade with a table name.

For plain data changes inside a migration, the DB facade is usually the better choice. Here’s why:

1. Stability

Models don’t always live forever. You might rename them, move them to a different namespace, or swap out a package that defines them. When that happens, any migration referencing that model breaks retroactively, even if it ran fine the day you wrote it.

The table name is a much more stable contract. Binding the migration to the table keeps it working even as your application code evolves.

2. Side Effects

Migrations live at the database layer, not the domain layer. Models accumulate behavior over time—casts, global scopes, or observers—that can produce unintended side effects when running a migration. Using the DB facade bypasses these application-level behaviors, ensuring your migration only does exactly what you expect.

While there are times when using a model is appropriate, defaulting to the DB facade for data migrations is a safer bet for long-term maintainability.