Laravel Large Table Backfills: Why They Don't Belong in Migrations

A post on Medium warns Laravel developers against running a backfill on a large table directly inside a migration. For schema changes that must stay safe while several application versions run at the same time, the author suggests a four-phase pattern: expand, dual-write, restartable backfill, and contract.

Four phases for a safer Laravel backfill

The source only includes a short summary, so the technical details are in the full article on Medium. From that summary, here is a general picture of each phase:

• Expand: add the new structure, such as a column or table, without removing the old one. Older versions of the application keep working.
• Dual-write: the application writes to both the old and the new structure, so new data is not left behind.
• Restartable backfill: existing data moves to the new structure in batches. The process can be stopped and resumed without starting over.
• Contract: once everything is done, the old structure is removed.

Why not inside a migration? Migrations usually run during deployment. If the table is large, heavy work inside the migration can hold up the entire release. Splitting the work into phases lets the backfill run as its own process that you can monitor and repeat.

The most interesting point is the mention of mixed application versions. While a deploy is in progress, old and new versions of your application can run side by side for a while. The database schema has to work with both, which is why the change is split into steps instead of made all at once.

If you maintain a Laravel application with tables holding years of data, such as orders or transactions, this pattern is worth studying before you schedule your next schema change. The full post on Medium has the details on how to apply it.