This is great, really worth reading if you're interested in transactions.
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.
DSQL is so cool - have been following since the release and once it supports more of the postgres feature set + extensions it’ll be a killer. Fantastic architecture deep dive at ReInvent as well.
> 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.
MySQL Serializable is pretty similar to serializable in other databases, in terms of the observable anomalies. There's a good set of tests here: https://github.com/ept/hermitage
> 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).
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.
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.
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.
This is great, really worth reading if you're interested in transactions.
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.
DSQL is so cool - have been following since the release and once it supports more of the postgres feature set + extensions it’ll be a killer. Fantastic architecture deep dive at ReInvent as well.
Hey Mark, I actually found this post via yours so thanks!
> 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.
MySQL Serializable is pretty similar to serializable in other databases, in terms of the observable anomalies. There's a good set of tests here: https://github.com/ept/hermitage
> 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).
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.
(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.
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.