Last updated on
Database Migrations
Is it ok to have huge migration files?
I like to use migration tools which have up and down(or revert) commands such as sqlx, golang’s goose, etc.
However, as the project grows, the migration files become huge and hard to manage.
Also, when learning about zero-downtime migrations, I found that I had to alter the tables multiple times,
resulting in multiple migration files which should have been a single migration file with a single CREATE TABLE statement.
As so, I wondered whether creating up sql statements multiple times was good practice.
I stumbled across a Reddit post
which talks about this,
and came across the conclusion below.
- It is ok to have a lot of migration files.
- At the end of development, you can squash them into a single file
- In production, the initial migration file will be huge, describing all the schema.
- After the initial migration, it is better to have multiple migration files which describe how the schema has changed over in the past.
Migration tools
I prefer migration tools which down commands, and which use raw SQL.
These are the tools that I prefer to use.