Proposal: Improving Migration Atomicity

[SamuelBisberg]

Problem

Migrations involving multiple schema changes are not always atomic across all supported databases. When a migration step fails partway, earlier changes may remain applied, leaving the database in an inconsistent state and breaking rollback workflows. This requires manual intervention to fix.

While some databases like PostgreSQL, SQLite, and SQL Server support transactional DDL and handle this safely, others—such as MySQL and MariaDB—do not, causing frequent partial migrations.

Database Transactional DDL Support & Usage

Database	Transactional DDL Support	Laravel Dev Usage*
PostgreSQL	Yes	~38%
MySQL	No	~83%
SQLite	Yes	~37%
SQL Server	Partial	Not specified

How Other Platforms and Frameworks Handle Migration Atomicity

Platform / Framework	Approach to Migration Atomicity	Notes
Ruby on Rails	Wraps migrations in transactions where supported	Skips transactions on MySQL to avoid false safety; strong_migrations gem provides safety checks
Django	Runs migrations transactionally where supported	Offers atomic = False flag; documents risks for non-transactional DBs like MySQL
Flyway	Uses transactional migrations if supported by the DB	Provides repair command to fix failed migration metadata
Prisma	Transactions used where supported	Has commands like prisma migrate resolve to recover from failed migrations
Laravel (current)	Does not wrap schema migrations in transactions by default	Recommends granular migrations; rollback and cleanup left to developer

* Based on Stack Overflow and community surveys

Proposed Solutions

1. None - keep current behavior

Pros:
✅ No breaking changes or disruptions to existing workflows
Cons:
⚠️ Partial migrations and rollback failures remain common
⚠️ Manual cleanup still required after failures

2. Use transactions for migrations

Pros:
✅ Full atomicity and safe rollbacks where supported
✅ Prevents partial application of migrations
Cons:
⚠️ Not supported on all databases (e.g., MySQL/MariaDB) due to implicit commits
⚠️ May create false confidence where transactions don’t actually protect changes

3. Use transactions with a protected field indicator

Pros:
✅ Wraps migrations in transactions while excluding operations that break transactional guarantees
✅ Improves safety without breaking compatibility on databases without full transactional DDL support
Cons:
⚠️ Adds complexity to migration tooling and developer workflow
⚠️ Requires explicit marking of non-transactional operations

[shaedrich]

Problem

Migrations involving multiple schema changes are not always atomic across all supported databases. When a migration step fails partway, earlier changes may remain applied, leaving the database in an inconsistent state and breaking rollback workflows. This requires manual intervention to fix.

While some databases like PostgreSQL, SQLite, and SQL Server support transactional DDL and handle this safely, others—such as MySQL and MariaDB—do not, causing frequent partial migrations.

This is a huge problem! Thanks for bringing that up, Samuel! 👍🏻

I'd say, one of the problem is that the migrations table only knows two states: migrated and not migrated. For migrations, which aren't atomic, it would be nice if Laravel would internally split the migrations into multiple sub migrations (implementation would be discussed then) and display how many of the total steps of the migration are applied as well as offering to rollback partial migrations.

[hafezdivandari]

Laravel does not wrap schema migrations in transactions by default.

What is your reference? Check the following codes please, what am I missing?

framework/src/Illuminate/Database/Schema/Grammars/Grammar.php

Lines 499 to 507 in 39e9e2b

	/**
	* Check if this Grammar supports schema changes wrapped in a transaction.
	*
	* @return bool
	*/
	public function supportsSchemaTransactions()
	{
	return $this->transactions;
	}

framework/src/Illuminate/Database/Migrations/Migration.php

Lines 14 to 19 in 39e9e2b

	/**
	* Enables, if supported, wrapping the migration within a transaction.
	*
	* @var bool
	*/
	public $withinTransaction = true;

framework/src/Illuminate/Database/Migrations/Migrator.php

Lines 445 to 448 in 39e9e2b

	$this->getSchemaGrammar($connection)->supportsSchemaTransactions()
	&& $migration->withinTransaction
	? $connection->transaction($callback)
	: $callback();

framework/src/Illuminate/Database/Schema/Grammars/PostgresGrammar.php

Lines 13 to 18 in 39e9e2b

	/**
	* If this Grammar supports schema changes wrapped in a transaction.
	*
	* @var bool
	*/
	protected $transactions = true;

framework/src/Illuminate/Database/Schema/Grammars/SqlServerGrammar.php

Lines 11 to 16 in 39e9e2b

	/**
	* If this Grammar supports schema changes wrapped in a transaction.
	*
	* @var bool
	*/
	protected $transactions = true;