iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
php artisan schema:dump --prune creates a SQL snapshot of the current database schema in database/schema and removes existing migration files. Laravel can use that snapshot to build a new database before running migrations created after the dump. The workflow is useful, but a clean setup depends on committing the snapshot and creating one for each database connection that needs it.
What does php artisan schema:dump --prune do?
The schema:dump command writes the current database structure to a SQL file under database/schema. Its filename corresponds to the database connection. Adding --prune tells Laravel to remove the existing migration files after creating the dump. This consolidates the starting schema without preventing you from adding new migrations afterward.
When Laravel migrates a connection that has no migrations recorded, it loads the connection’s schema file first, then runs migrations that are not represented in the dump. This is how a new database can be brought up to date without replaying the full historical migration set. See Laravel’s Laravel 10.x migration documentation for the version-specific command behavior and setup details.
Recommended Free Tools
Do I commit the schema file?
Yes. Laravel’s migration documentation says to commit the database schema file to source control so a new developer can create the application’s initial database structure. If you prune the migration files but omit the corresponding schema dump, a clean checkout may not have the artifact Laravel needs for that starting structure.
#1 Best Overall
Review the changes to database/schema alongside the migration changes in the same commit. The dump is a maintained project artifact, not a substitute for source control or a reason to discard migrations created after it.
Five team risks to check before pruning migrations
1. The dump is missing from source control
A developer or CI job building a fresh database needs the schema artifact for the relevant connection. Confirm the dump is tracked and included in the branch or release that removes the old migration files.
2. Tests use a different database connection
List the connections used by local development, CI, and tests. If tests use a separate connection, Laravel’s documentation advises creating a schema dump for it too; the documented example is php artisan schema:dump --database=testing --prune. Without the appropriate dump, a test database initialized from scratch may not have the expected starting schema.
3. The database driver or command-line client is not available
Laravel 10.x documents migration squashing support for MySQL, PostgreSQL, and SQLite, and says the operation uses the database’s command-line client. Check the migration documentation for the exact Laravel version in your project, along with the client tooling available wherever the command runs. Do not assume the Laravel 10.x driver list applies unchanged to other releases.
Rank #3
4. Pooled PostgreSQL connections cannot perform schema operations
For Laravel 13, the database documentation describes configuring a direct PostgreSQL connection for migrations, schema dumps, and restores when transaction pooling is in use. A pooled endpoint may not be suitable for those operations; confirm the direct connection details and credentials work in the environment that runs them. See Laravel 13.x database documentation.
5. A secondary database’s migration tracking is assumed rather than verified
A reported issue describes a two-database setup on Laravel 8.69.0, PHP 8.0.10, and MySQL 5.7 where the secondary database had no separate migrations table. The issue page is marked closed but does not state how it was resolved, so it is evidence of a version-specific report—not proof of a current Laravel defect or a general rule about multiple databases. Check the tracking-table and schema-dump behavior for the release and connection configuration your application actually uses: Laravel Framework issue #39476.
Does schema dumping work with multiple databases?
Laravel’s schema files are associated with database connections, so treat each connection as a separate clean-install requirement. For every connection your application migrates—including a distinct testing connection—verify that its schema artifact is created, committed, and usable in the relevant environment. The Laravel 8.69.0 issue above concerns a specific secondary-database tracking arrangement; it does not settle behavior for every release or configuration.
Keep deployment migration execution separate from squashing
Pruning migration files and coordinating migrations during deployment are different concerns. Laravel 10.x documents php artisan migrate --isolated for deployments running from multiple servers: it acquires a cache-backed atomic lock, and all servers must use the same central cache. This is a deployment coordination mechanism, not evidence that schema:dump --prune is inherently unsafe.
Decide whether pruning fits your project
There is no universal migration count or performance threshold in the cited documentation that makes squashing the right choice. Compare the operational value of a shorter migration history with what your team needs to reproduce and understand database changes.
- Clean installs: Can a new checkout build each required database from its committed schema dump and subsequent migrations?
- Connection coverage: Are local, CI, test, and production migration connections accounted for separately?
- Tooling: Does the Laravel release and database driver support the workflow, and is the required command-line client available?
- History needs: Does your team rely on old migration files to explain or audit how the schema evolved?
- Operations: Do deployment locking and any PostgreSQL connection-pooling requirements match the way migrations and restores run in your environments?
Answer those questions against the documentation for the Laravel version you deploy, rather than assuming that behavior documented for another release applies to your application.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
