Rails migration rollback scope: restoring schema without expecting deleted data back

Yes—define your policy boundary as schema compatible with the previous code version. rails db:rollback is a structural operation: it runs the migration's down method (or the inverse of change) and moves the version pointer in schema_migrations back. It never snapshots, copies, or restores row data. "Full pre-migration state" is unachievable through migrations alone, so your policy should state that data recovery is delegated to backups, point-in-time recovery, or application-level soft deletes—not to rollback.

What each operation in your set does on rollback

Assuming a current Rails 7.x line with PostgreSQL:

• remove_column without options: irreversible in change. Active Record cannot guess the dropped column's type, so rollback raises ActiveRecord::IrreversibleMigration. You can make it reversible in place by passing the type explicitly—remove_column :users, :legacy_flag, :boolean—but note the recreated column comes back empty (or with a default), never with the old values.
• change_column: not invertible from change because the old type isn't recorded in the call. Rewrite as up/down, or use change_column inside reversible blocks. Even when reversed, values truncated or coerced by the type change (e.g., string to integer) are not restored.
• execute (raw SQL): always irreversible from change. Wrap it in up/down with a hand-written inverse, or in a reversible block. If the SQL deletes or transforms rows, your down can only undo structure—it cannot reconstruct deleted rows.

Where expand/contract fits

Expand/contract (add new structures, migrate reads/writes, remove old structures in a later deploy) narrows the window where destructive rollback matters, but does not eliminate it. During the expand phase, rollback is safe because nothing was dropped. Once you ship the contract phase—the migration that actually drops the old column—rollback of that step is again schema-only. The pattern's real benefit is that by the time you drop anything, the data is usually already duplicated or obsolete, so the missing data restoration stops mattering. It is a deployment-safety strategy, not a data-recovery mechanism.

Verifying your assumptions before writing the policy

These checks are cheap on a staging or development copy and confirm the behavior for your exact Rails version:

# 1. Confirm structural reversal with no data recovery
bin/rails db:migrate
bin/rails db:rollback
bin/rails db:migrate:status   # version pointer moved back

# 2. Drop a populated table, roll back, inspect
bin/rails runner 'puts User.count'   # after rollback: table exists, 0 rows

# 3. Confirm irreversibility of raw SQL in change
bin/rails db:rollback   # => ActiveRecord::IrreversibleMigration

Also diff db/schema.rb before and after rollback to confirm the structure returned to the prior version.

Recommended policy wording

Write the policy as: rollback guarantees the schema matches the previous deployable code version; every destructive migration must be reversible (up/down or reversible) and must be preceded by a verified backup or table-level copy of affected data; recovery of deleted rows is a restore-from-backup runbook, not a rollback runbook. One caveat to flag for review: exact error text and STEP option behavior can vary slightly across Rails minor versions, so pin the verification steps above to the version you actually run in production.