Decomposing Transactional Systems
commit version is chosen — the time at which the database claims all reads and writes occurred atomically.
This post doesn't mention transaction isolation specifically though it does say "How does this end up being equal to SERIALIZABLE MySQL?" So maybe I'm supposed to consider this post only for 'Every transactional system' running with SERIALIZABLE transaction isolation. I don't particularly care about that. I do care that the database I use clearly states what its isolation names mean in detail and that it does exactly what it says. e.g. I don't expect MySQL SERIALIZABLE to exactly mean the same as any other database that uses the same term.
So maybe I'm supposed to consider this post only for 'Every transactional system' running with SERIALIZABLE transaction isolation.
No, it's a general point about the nature of transactions in DBMSs, and the different implementation choices. As the article says, there are some variations (e.g. MVCC at levels lower than serializable inherently has two 'order' steps).
MVCC databases may assign two versions: an initial read version, and a final commit version. In this case, we’re mainly focused on the specific point at which the commit version is chosen — the time at which the database claims all reads and writes occurred atomically.
For non-SERIALIZABLE isolation there may be no such "time at which the database claims all reads and writes occurred atomically", which is how I took the rest of the post to mean when running with SERIALIZABLE isolation.
It is written with a lean towards serializable, partly because there's a wide variety of easy examples to pull which all implement serializable, but the ideas mostly extend to non-serializable as well. Non-serializable but still MVCC will also place all of their writes as having happened at a single commit timestamp, they just don't try to serialize the reads there, and that's fine. When looking at non-serializable not MVCC databases, it's still useful to just try to answer how the system does each of the four parts in isolation. Maybe I should have been more direct that you're welcome to bend/break the mental model in whatever ways are helpful to understand some database.
The line specifically about MySQL running at serializable was because it was in the Spanner section, and Spanner is a (strictly) serializable database.
Moving to serializable should be easy but isn't in the case of Spanner and the like because you can't make 100+ of sub-millisecond queries to respond to an API request if that's how your app evolved.
The way I imagine the future is to bring the code closer to the data like stored procedures, but maybe in a new way like modern languages compiled to run (and if necessary retry) in a shard of the database.
I liked it so much I wrote up how the model applies to Amazon Aurora DSQL at https://brooker.co.za/blog/2025/04/17/decomposing.html It's interesting because of DSQL's distributed nature, and the decoupling between durability and application to storage in our architecture.