The Excel User's Guide to Databases: Migrations
Why your feature is held up by a migration and why this is actually good.
Last updated: March 3, 2025
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.
Context: your developers are using an ORM
At its core, a database migration involves taking schema changes and applying them to your database.
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?
An ORM is software that lets developers interact with their database in their programming language of choice – instead of SQL. It’s pretty standard for developers to use some sort of ORM for building applications, and there are different ones for each popular programming language.
SQL is great. In fact, it’s probably the language I’m best at (although this may not mean much). The issue is that when you’re building an application, you’re primarily writing in an object oriented programming language like JavaScript or Python. These things work differently than SQL.
If you want to issue SQL statements against your database from your web app, you’d need to create these large, unwieldy strings:
var database = database.connect()
var sql_statement = “””
SELECT
…
…
“””
database.execute(sql_statement)
When statements get sufficiently complex – especially when you need to interpolate custom data into them before you send them to the database – this makes for a frustrating developer experience.
What an ORM does is bridge the gap between these two things – SQL and object oriented programming – by wrapping around your database with nice, ergonomic functions that more closely map to how developers build apps. In short, using an ORM is the difference between this:
SELECT
username,
email
FROM users
WHERE user_created_at = ‘01-01-2022’
And this:
var user = users.where({ user_created_at: ‘01-01-2021’ })
The former is plain SQL; the latter is a user object with a .where method that a dictionary is passed into as a filter. It’s exactly the same “request” from the database, but the ORM lets you write it like you would a line of normal code. Behind the scenes, the ORM is taking th...