Rails Migrations

Use for schema changes and migration safety.

Rules

• Make migrations reversible whenever possible (reversible blocks with explicit up/down SQL for data moves).
• Use raw SQL for data manipulation inside migrations; avoid referencing app models that drift over time.
• Avoid long table locks on large tables; split risky work into multiple deploy-safe steps.
• Separate schema changes from heavy data backfills.
• Prefer database operations that remain safe when rerun (table_exists? / column_exists? guards where migrations may run against varied states).
• Small inline backfills are fine in one migration (add column → execute "UPDATE ..." → tighten constraint); anything long-running moves out of the migration path entirely.

Script Backfills (not everything is db:migrate)

Long-running or risky data backfills live in script/migrations/*.rb, run manually (e.g. via Kamal), not in the deploy migration window: