[latch]

I don't know Django and what Django-specific problems/solutions are available, but AFAIK the only scalable (and largely language agnostic (1)) solution is to break these down and deploy incremental versions of the app.

For example, they give an example where widget_description is being added which must be not null. But this should be two migrations: 1) adding the column, 2) making it not null. And because these are now split, they can make incremental changes to the app to accommodate these migrations - the first version working when widget_description is nullable and the second, after the data is fully migrated, when it isn't.

(1) If you're using any `select *`, it's important that your ORM ignores unknown columns (e.g. newly added). I've inherited systems that used libraries that behaved like this, and it's awful.

[bpicolo]

Postgres has been able to safely add a not-null column with a default since version 11 (2018).

https://www.postgresql.org/about/news/postgresql-11-released...

[latch]

Some migrations are non-trivial and might take hours or days (e.g. they could involve hitting external services, or might require manual work). Sure you can default these, but `null` is probably semantically correct in most cases

[true_religion]

Isn't that painfully slow in production? Or is that a mistake on my part?

[scrollaway]

You might be thinking of older postgres. See this SO: https://dba.stackexchange.com/a/211222

[singron]

Rails used to cache the list of columns after the first query and then expect all of those columns on subsequent queries. It made it so that if you removed an unused column, all your queries would fail until you restarted your rails processes.

[byroot]

That's what `ignored_columns` is for: https://api.rubyonrails.org/classes/ActiveRecord/ModelSchema...

[nijave]

Semi related https://github.com/ankane/strong_migrations

[code_biologist]

One of my favorite explanations of how to do incremental versions: https://stripe.com/blog/online-migrations