This is great, really worth reading if you're interested in transactions.<p>I liked it so much I wrote up how the model applies to Amazon Aurora DSQL at <a href="https://brooker.co.za/blog/2025/04/17/decomposing.html" rel="nofollow">https://brooker.co.za/blog/2025/04/17/decomposing.html</a> It's interesting because of DSQL's distributed nature, and the decoupling between durability and application to storage in our architecture.
> commit version is chosen — the time at which the database claims all reads and writes occurred atomically.<p>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.