Zero-downtime model updates on a live Turnkey instance — what actually happens?

I understand that changing the model updates the database schema. What I want to know, as the
person who gets paged, is what happens to in-flight requests during that update.

Specifically: additive changes (new attribute), destructive changes (dropped attribute), and
renames. Are they equivalent operationally or do they need different handling?

They are not equivalent, and it is worth being precise about it.

  • Additive — new class, new attribute, new association. Safe. The schema gains something
    nothing is reading yet. In-flight requests are unaffected.
  • Rename — treated as a drop plus an add unless you tell the evolution otherwise. This is
    the one that surprises people, because the data goes with the dropped column. Use the
    evolution’s rename handling rather than editing the name and hoping.
  • Destructive — dropping an attribute or an association. The data goes. Take a backup
    first, every time, no exceptions for “it is only a test column”.

For anything beyond additive on a production instance, take the window. The operation itself
is fast, but a request that starts before and finishes after a schema change is not
something anyone should be reasoning about at 2am.

The rename-is-a-drop-plus-add point is the answer I came for. That is going in the runbook in bold.

Learned that one the expensive way on a client system. A column named Notes became CustomerNotes and eight years of notes went with it. The backup existed, thankfully.

This thread is now a runbook. Thanks both.