Laravel Schema Dump: how to speed up your migrations?

Large or long-lived applications can have this issue, a huge list of migration files that were created more than a few years ago. These will never change again and are slowing down your tests. How can you improve this?

In Laravel 8, which will be released later this year (planned on 8 September 2020), Taylor Otwell added a new feature called "Schema Dump". This creates a dump of the current schema state using mysqldump or pgdump.

Why should you use Schema Dump

First of all, speed. When you have a lot of different migrations it takes a long to time run all those migrations for the tests. When you only have to execute one file it will save you a lot of setup time.

Also, developers want to have a clear overview of the files, folders, controllers, etc. Why wouldn't you clean up the database migrations that already have been deployed to production? You probably don't want to change them again, especially when it's more than a year ago.

How to use Schema Dump

The command can be called using:

php artisan schema:dump

or

// Dump the current database schema and prune all existing migrations...
php artisan schema:dump --prune

Please note, at this moment it is only available for the MySQL, PostgreSQL, and SQLite databases.

Interested in how this feature works behind the scenes? Check out the pull request on Github via https://github.com/laravel/framework/pull/32275.

Migration Squashing

In the upgrade guide to Laravel 8 it's referenced as "Migration Squashing".

Taylor Otwell created this pull request and wrote this about the feature:

This PR adds support for a new php artisan schema:dump command which uses mysqldump or pgdump to dump the current state of your schema to a database/schema/{connection}-schema.mysql file.

When this file exists and php artisan migrate or php artisan migrate:fresh is run AND no migrations have run against the database yet (migrations table is empty), this schema file will be loaded into the database first and then any outstanding migrations will be run. This means that effectively this schema file would typically only ever be used during local development or during CI testing. In production, you would typically already have migrations that have run in the past so this schema file would never be triggered.

The official documentation for Laravel 8 Squashing Migrations, this can be found on https://laravel.com/docs/8.x/migrations#squashing-migrations.