[karmakaze]

I'm not seeing the mention of two 'order' steps. Are you referring to the larger part of what I quoted?

> 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.

[transactional]

(Hi! Post author here.)

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.

[karmakaze]

Thanks for the clarifications and diagrams. I can see how using something like Spanner from the outset makes sense to use and stick with serializable isolation. With other SQL dbs, I've mostly seen repeatable read, read committed, and even read uncommitted used in the name of performance. Read committed works fine but you have to design everything for it from the start with thoughtful write and read sequences.

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.