Schema Evolution Without Breaking Clients

1. The Constraint That Makes This Hard

A schema change looks like a single event and never is. In any system with more than one running process, there is a window during which the old code and the new code are both live, reading and writing the same data.

That window is not an implementation detail of your deployment. It is a constraint on the change itself.

Any schema change has to be compatible with both the old code and the new code, in both directions, for as long as both are running.

The length of that window is longer than people assume