Does YugabyteDB Need a Compensating Transaction for Partially Applied Online Schema Changes?

The goal is to guarantee that a schema change applied via YugabyteDB's online DDL can be safely reverted if the migration has only progressed on a subset of tablets, without risking data loss or inconsistency.

Currently, once a background migration starts altering tablets, there is no built‑in mechanism to roll back those tablets to the previous schema; certain DDL operations such as adding a NOT NULL column with a default or changing a data type are irreversible once the table rewrite begins. This raises an open design question about whether a compensating transaction or manual rollback procedure should be introduced for partially propagated changes.

• Should YugabyteDB provide a manual rollback procedure for tablets that have already migrated?
• Could a compensating transaction be added to revert both metadata and data changes safely?
• What performance and consistency implications would such a rollback mechanism introduce?