Rails migrations are useful any time you need to make a change to your application’s database. If you’re working with Rails Active Records, manipulating the database directly is a bad idea.
As we’ll see in the example below, Active Record uses migrations to update your app’s schema in schema.rb. This file is what Rails uses to deploy your application to a new database. So using migrations makes it possible for you to deploy your app to new platforms. You can develop on one database and deploy to another, or deploy to a new database platform in production.
Migrations are saved as part of your Rails project, so they’re versioned with the rest of your code. They’re also easy to share across development teams since each member of the team can deploy the migration to their local instance when they update their projects.
Add a column
One of the most common changes in an app is adding a field to an existing object. So adding a column to a database is a typical migration. If you’re working with Active Records, Rails will create the migration for you.
You can use all of the Rails basic data types with migrations, and it’ll be matched to the corresponding type in the database you migrate to. Here’s a list of data types:
You can also specify a database-specific data type for a column, but this may cause problems if you try to migrate your application to a new platform.
Change a column
You can change an existing column to a new name or data type as well. Rails migrations know how to move data to a new type. Column changes, however, aren’t reversible.
Add a new model (or table)
Adding a new class to an application is a frequent change too. When you add a new model to a Rails application, it generates a migration to create the corresponding table for you. If that’s not what you need, you can write your own.