Drupal Update API + Database Abstraction Layer: Is Automatic Schema Rollback Feasible?

Short answer

No. Drupal core (including Drupal 10/11) provides no mechanism to automatically revert schema changes applied by hook_update_N when a later update fails. The Update API records that an update ran; it does not record how to undo it. Rollback safety today comes from external backups taken before running updates, not from Drupal itself.

Why automatic rollback is fundamentally hard

The blocker is not just missing bookkeeping — it is how the underlying databases behave.

• DDL causes implicit commits. On MySQL and MariaDB (the most common Drupal backends), statements like ALTER TABLE, CREATE TABLE, and DROP COLUMN commit the current transaction implicitly. Wrapping a hook_update_N in a transaction does not protect you: once the DDL executes, it is durable. PostgreSQL supports transactional DDL, but Drupal must behave consistently across drivers, so core cannot rely on that.
• The Update API tracks completion, not state. Executed updates are recorded in the key-value store as a schema version number per module. There is no snapshot of the table structure before the change, and no inverse operation is generated.
• Inverse DDL is not derivable. Even with a version history, reversing DROP COLUMN cannot restore the data that was in the column. Some operations are inherently one-way, which is why a generic auto-rollback would give false confidence even if it existed.
• Config API rollbacks don't help. Configuration import/export operates on config entities, not on table structure. Reverting config will not recreate a dropped field storage table.

What actually happens on failure

The update runner executes pending updates sequentially. If update N+3 throws, updates N through N+2 remain applied — both their schema changes and their "completed" markers. Re-running update.php or drush updatedb resumes from the failed update; it does not undo anything. You can verify this in a development environment by writing a module with two updates where the second throws deliberately: the first update's schema change persists.

Best practices for rollback safety

1. Snapshot before updating. Take a database dump or filesystem-level snapshot immediately before running updates. With Drush: drush sql:dump --result-file=pre-update.sql, then drush updatedb. On failure, restore the dump and the previous codebase together — schema and code must match.
2. Deploy code and database as a unit. Keep the pre-update database backup paired with the exact code revision, so a restore never leaves code expecting tables that no longer exist (or vice versa).
3. Stage first. Run the full update against a copy of the production database in staging. Updates that pass on an empty dev database can still fail on production-scale data.
4. Write defensive updates. Use the schema API's existence checks ($schema->tableExists(), fieldExists()) so a partially-applied update can be safely re-run. Make data migrations resumable via the $sandbox batch mechanism rather than monolithic loops.
5. Prefer additive changes. Adding a column is far safer to retry than renaming or dropping one. Where possible, split destructive changes into a later update after the new structure is proven.

Is versioned schema migration coming to core?

The need for a versioned, reversible migration system has been raised repeatedly in the Drupal issue queues and community discussions over the years, but as of this writing there is no accepted core initiative that adds automatic schema rollback to the Update API. The implicit-commit problem on MySQL means any such feature would still require backup-based recovery for destructive changes, which weakens the case for building partial rollback into core. Treat any claim of an active, landed proposal as needing verification against the current drupal.org issue queue before relying on it.

Bottom line

Automatic schema rollback is not feasible as a general core feature, primarily because DDL cannot be transactionally reversed on Drupal's most common database engines and because destructive changes are not invertible at all. The supported, reliable strategy remains: backup before updates, test on a production copy, write idempotent updates, and restore code-plus-database together when something fails.