еще пару постов, и mvcc будет изобретен в очередной раз повторно, после первого изобретения в 1978 году.
Но там вполне допускается и наоборот.
Новое значение состояния пишется в старое поле, а старое значение уходит в новую историю состояний.
Как показывает Oracle, на живом собственном примере - тоже вполне удачный вариант (попробуй обгони).

Говорят, что любая из известных к настоящему моменту, и используемых в бд схем обслуживания concurrency,
в комбинации с параллельностью поступающих запросов, масштабируется в весьма ограниченном диапазоне конкурирующих запросов.

Кто-то лет 15-20 назад моделировал для классических disk oriented систем, что в любом случае, в районе 1000 процессов, какие схемы
ни катай, возникает гарантированный stop the world.

Просто у некоторых схем он возникает раньше, а других позже, какие-то третьи скатываются плавнее к состоянию непроходимости.

Что интересно, по какому-то совершенно случайному совпадению, число ядер в современных серверных процессорах
(~64 физических) практически совпадает с максимумом пропускной способности произвольной схемы обеспечения concurrency,
которая в тогда была оценена где-то в 128 конкурирующих процессов для любой схемы.