ADR Does Not Reverse Committed Schema Changes in Azure SQL Database

Accelerated Database Recovery (ADR) in Azure SQL Database is documented to shorten rollback and crash recovery through a persisted version store. While most DDL is transactional and an uncommitted ALTER TABLE can be reversed with ROLLBACK TRANSACTION, ADR does not make a committed schema change undoable. After a COMMIT TRANSACTION, reversal requires a database-level point-in-time restore limited by backup retention.

Even for uncommitted changes, ADR reduces undo duration but does not remove schema-modification lock contention, tempdb usage, or transaction-log growth during rollback. ADR availability and exact locking behavior depend on service tier, hardware generation, and engine version, while certain online index or replication-related DDL carries separate restrictions.

Is there a documented size, duration, or resource threshold that indicates a schema change has become unsafe to roll back in place, even with ADR enabled? How can a team confirm that ADR is actually reducing rollback blocking on their specific service tier before depending on it? What monitoring signals distinguish a progressing uncommitted DDL rollback from one that is escalating lock contention?