Delta Lake rollback after a schema change: RESTORE to an old version or additive-only evolution?

A Delta Lake table on Apache Spark receives frequent schema changes: new columns in most releases, and occasionally a column drop or type change that later has to be undone. The goal is to choose one documented rollback strategy that keeps the table recoverable without breaking downstream Spark jobs.

Two documented approaches fit. Time travel with RESTORE returns the table to an earlier version, including the schema recorded in the transaction log, but it is metadata-only: newer files remain, recovery depends on retention surviving VACUUM, and readers pinned to the newer version can break. Additive-only evolution via mergeSchema or schema.autoMerge rules out destructive changes, so rolling back code alone stays safe, but a wrong column type cannot be corrected that way. Retention defaults and column-mapping behavior vary by Delta Lake version.

The unresolved decision is where the rollback boundary lies once a destructive change has already been read by other pipelines.

• Which strategy gives a safer boundary for a table with multiple downstream consumers: RESTORE to the pre-change version, or additive-only changes?
• What retention planning keeps a restored version and its history readable for as long as rollback might be needed?
• After downstream jobs have consumed the changed schema, what determines the latest version to which a restore is still safe?