Post #7 - MVCC at Microsecond Scale: Snapshot Isolation Without Cloning Rows

[nockawa]

An entity with eight components takes a hit and loses three health. In textbook MVCC, that one-field write clones all eight columns into a brand-new row — the position it didn't move, the name it didn't change, copied and left behind as garbage for a vacuum to sweep later. 🧬 → ⛓️

Typhon writes one revision. Just the health chain gets a new entry; the other seven components never know anything happened.

The trick is versioning by component instead of by row: a 12-byte chain entry, a one-byte visibility rule (committed AND TSN <= snapshot), and a top bit that hides an in-flight write from every other reader without either side ever taking a lock to check.

Payoff: reads hold at ~80 ns, writes at ~250 ns, flat regardless of how many times the value has changed — and it's cheap enough per-component that a hot, history-less field can opt out of versioning entirely and run at ~15 ns.

The honest part: two transactions writing the same component never block or abort — the conflict is resolved at commit, and the default resolution (last-writer-wins) is fine for a position and a footgun for a gold balance. That's what the optional conflict handler is for.

🔗 https://nockawa.github.io/blog/mvcc-at-microsecond-scale/