[awinter-py]

Hmm -- most migrations don't need to be reversed, not sure what the 'down' section does in those cases.

The more important problem in DB migrations is transforming the content (usually involves application code) and resolving relational changes (i.e. 'in v2 all users are a member of a group').

Some large companies handle migrations by versioning the data and branching the code to handle every version. Another alternative is to 'migrate on read'.

Both of those options sound worse on paper than an all-at-once migration but one-shot upgrades can be expensive and dangerous on large databases. Dealing with data-versions explicitly also makes sense for data that's stored client-side and periodically synced.

[GrinningFool]

> Hmm -- most migrations don't need to be reversed,

This is true - but when something does break unexpectedly in a production migration, the last thing you want to do is figure out how to do your revert/'down' on the fly.

[awinter-py]

Okay, but are you testing every 'down' command on your prod DB? Large untested operations in prod may not be the best answer in an emergency.

[Kiro]

> most migrations don't need to be reversed

What do you mean? That's like saying "most commits don't need to be reverted".

[awinter-py]

But git rollback is something you get for free. These 'down' commands have to be written and tested.

[elwinar]

> most migrations don't need to be reversed

I agree, in which case, you don't have to write a down section.

Anyway, rambler isn't targeted at "large companies with huge databases", which of course have more complex database migrations methods.

[tomcam]

Great getting a perspective from the trenches, thank you. Never heard of forking code for each migration.