Rails Database Migrations Best Practices - FastRuby.io | Rails Upgrade Service

Database migrations are designed to be temporary. They serve as a bridge to implement incremental changes but aren’t meant to stick around indefinitely. Once they’re run, particularly in a production environment, they’ve done their job. The schema file then becomes the definitive source of truth for the database structure, as it reflects the database’s current state after all migrations have been applied. Migrations, especially in production or staging, don’t need to be executed repeatedly. After being run, their purpose is fulfilled (unless you need a rollback). In development or test environments, we can reload the database schema with bin/rails db:schema:load to stay in sync, rather than relying on a long chain of migrations. There’s an argument for keeping migration files for historical context, as they can show how the database evolved over time. In these cases, archiving older migrations might be a cleaner approach than just deleting them.