For some reason, people seem to have an issue with migrations … they get them confused with schemas. Allow me to explain.

A lot of people seem to sit on changes they want to make models, collecting changes for “one big migration.” As if it were of utmost important that the migration be complete.

Migrations are meant to encapsulate a single set of modifications to your database schema. If you discover suddenly that that your table doesn’t have columns x, y, and z, and you need them for a model, make a migration for it. Don’t hold out on the off chance that you’ll come up with more changes in 10 minutes. Taking care of business, and take care of it now.

Let me give you a few reasons why you shouldn’t be afraid of just migrating already:

1. Smaller migrations mean there’s less of a chance of making an error in the middle. Migrations that fail in the middle are a whole lot of fun to fix, right?
2. Smaller migrations make writing self.downs easier; less looking back and forth (if you’re not using a handy feature of your editor/IDE to write them for you)
3. Naming smaller migrations is easier— there’s less change in the migration you need to describe
4. More migration numbers mean you can roll back with finer granularity if you need to
5. Faster changes == Agility. If you don’t care about agility, you just might be using the wrong framework.
6. There’s no reason not to (unless you’re afraid of another file— eeek!)
7. “Speed” concerns are poppycock. At over 500 migrations on my mega app, running db:migrate chugs along handily.
8. A migration number is not sacrosanct. Ruby can count forwards and backwards faster than you can, and, surprisingly, absolutely no puppies or kittens die if you have more migrations.

And there you have it.