That is a very reductionist view and not particularly useful either. It shares elements with versioning and you could likely implement this using explicit versioning, but it is completely independent of it.

The main difference I see is that of focus here the focus is to migrate a database without downtime or excessive global locks, keeping multiple versions of the schema is a detail.

Seems like you agree with my assessment.

:(

Things can have similarities without being the same. Also not being unique is not a moral failure.

I think I am failing to understand your stance.

Saying the pattern is the same isn't the same as saying two things fitting the pattern are the same in every respect.

Patterns are necessarily reductionist, like any sort of comparison of things that aren't 100% similar.

There is value in recognizing patterns. They're useful for comprehension and memory.

> This is the same pattern as versioning

I guess we disagree on the reasonable interpretations of this sentence

That's only half of the sentence

> "Versioning is a concept where each version lives in non-intersecting time intervals."

Is it? Node.js publishes "Current", "LTS" and "Maintenance" versions, and there's always a reasonable time interval during which consumers typically upgrade from eg Maintenance to newer LTS or even Current. From the publishing side, that's very similar to "expand and contract", in temporarily expanding what's supported to include Current, and dropping support for oldest versions leaving Maintenance. It's continuous instead of ad hoc, and there are more than 2 versions involved, but the principle is basically the same (at least if you squint).

Though I guess if you're talking strictly about schema management strategies, then yeah, "versioning" might be very different from "expand contract", as you noted.

It is often necessary to use multiple versions at the same time