I’ve found “downgrade” mostly useful for quick iteration during local development (where you may well not care about lost data). Realise your initial cut of the migration wasn’t quite right? Run “down” then fix it, then “up” again.

In what sense is 'downgrade' not just that prepared ahead of time? Or do you just not like the name?

Of course usually it would be followed by something that fixes it 'properly' - applying the original 'upgrade' again but with some correction, but typically that'll take longer than reverting to the previous version, and given it's gone wrong you'll probably want to take longer with it, test more, restore confidence.

downgrade implies that such a thing is possible. In a stateful system though, you cannot take back that which you have committed. It's quite literally impossible by definition.

No it isn't?

Forward migration: add date column, set = date(day, month, year) for existing records, drop is valid date constraint, drop day/month/year columns

Down migration: add day/month/year columns, add is valid date constraint, set day/month/year = appropriate datepart of date, drop date column

for trivial example.

>> This is why I've never used or understood the value of the "downgrade" feature in some database migration tools

It's technically a roll forward, while to most users it's more nature to say rollback/revert

It’s moving forward to get back to where you started