Hi there, blog author here!<p>This blog post is not a full description of CockroachDB&#x27;s transaction strategy. If you&#x27;re interested, you can find a complete rundown of our strategy here: (<a href="https:&#x2F;&#x2F;github.com&#x2F;cockroachdb&#x2F;cockroach&#x2F;blob&#x2F;master&#x2F;docs&#x2F;design.md#lock-free-distributed-transactions" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;cockroachdb&#x2F;cockroach&#x2F;blob&#x2F;master&#x2F;docs&#x2F;de...</a>). However, that is a very terse document: this blog post was an attempt to expand on one of the basic ideas behind our design. My goal to clearly explain how we approach atomicity, without broaching the complicated topic of Isolation.<p>That said, I will attempt to address some of the pain points you raised:<p>* Cockroach does use a full MVCC system; writes are &quot;append-only&quot; and we keep the full history of values for each key. Keys can be queried at a timestamp, and every write explicitly specifies a timestamp as well (each transaction is assigned a timestamp, all writes will use the same timestamp). With this system, each transaction operates on a snapshot of the database.<p>* Our strategy for overlapping transactions is straightforward: if two concurrent transactions have a conflict, one of them will be aborted and retried. Write intents (in combination with another component, the &quot;read timestamp cache&quot;) are used by conflicting transactions to discover each other. Once discovered, the decision of which in-progress transaction gets aborted is deterministic - each transaction is assigned a random integer &quot;priority&quot;, and the transaction with the highest priority always wins the conflict (unless one of the transactions has already committed).<p>* Every read does need to check the switch <i>if the key being read has a write intent</i>; reads of plain values (with no in-progress transaction) do not need to check a switch.<p>* Yes, aborted transactions can write intents to the database in our current system.  However, the second &quot;write&quot; (consolidation) happens asynchronously, and is not required for the transaction to function correctly. It should only be noticed if the key is accessed again by another transaction before it is consolidated. For committed transactions, I don&#x27;t believe this is a particularly high price to pay.<p>A system that doesn&#x27;t write aborted transactions to disk would be considerably more complex; I think it would involve two commit phases (I. The transaction has been &quot;committed&quot; in memory, and can no longer be aborted by other transactions II. The transaction must successfully commit all changes to disk in an atomic fashion). You likely could get some additional performance (if disk latency is a sufficient bottleneck), but it would be hard won in terms of complexity.