Zero-downtime Django migrations

52
1
16 days
(cheigh.me)
by cryvate1284

Comments

latch
13 days

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
12 days

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
12 days

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
12 days

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

scrollaway
12 days

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

singron
12 days

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
12 days
code_biologist
12 days

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