Error: Drift migration step fails, database left partially updated

Answer

Yes – you can execute several MigrationStep instances inside a single SQLite transaction by wrapping them in a manual database.transaction call. This makes the whole group atomic; if any step throws, Drift rolls back the transaction and the database schema stays at the version before the migration started.

Confirmed facts

By default Drift runs each MigrationStep in its own transaction, so a failure does not automatically undo earlier steps. The onError callback only logs and does not trigger a rollback. As of the latest stable Drift 2.x release there is no declarative rollback‑safe migration feature; manual transaction handling remains the only supported approach.

Steps to make a migration atomic

1. Create a custom MigrationStep (or use the onUpgrade callback of a MigrationStrategy) that opens a transaction.
2. Inside the transaction, invoke each step’s apply method (or execute the SQL directly).
3. If any step throws, the transaction is aborted and Drift treats the migration as failed, leaving the database at the previous version.

class AddUserTableStep extends MigrationStep {
  @override
  Future apply(DriftDatabase db) => db.transaction(() async {
    await db.into(db.users).insert(UserTableCompanion.insert(...));
    // … other schema changes …
  });
}

// Usage in a migration strategy
final strategy = MigrationStrategy(
  onUpgrade: (version, from, to) async {
    if (from < 2) {
      await database.transaction(() async {
        await AddUserTableStep().apply(database);
        await AddIndexStep().apply(database);
        // more steps …
      });
    }
  },
);

Verification: run a test migration where the second step throws an exception and confirm that the schema remains at version 1 (or whatever the starting version was). Drift’s own test suite shows this behavior when steps are wrapped in database.transaction.