The Excel User's Guide to Databases: Migrations

Why your feature is held up by a migration and why it's actually good

Been told by your engineers that your feature is ready to go, but they’re waiting on a database migration? This post will break down what a migration is, how ORMs do migrations, and why they can take so long.

This post is part of a paid subscriber only series that helps PMs, designers, marketers, and anyone else who works with engineers understand databases better. The previous post in the series covered schemas.

Context: your developers are using an ORM

At its core, a database migration involves taking schema changes and applying them to your database. If you’re wondering what a schema change is, check out the first post in this series.

If your application interacts directly with your database using SQL, schema changes get made unilaterally and at a point in time. Your database has whatever columns and tables you set it up with; you just get in there and issue some commands to change whatever you need to change. It’s quick and dirty (and dangerous, but more on that later).

But if your team is using what’s called an ORM, you’ll probably need to do migrations from time to time. So what is this ORM thing? And why does it seem to make your features take longer to ship?