DEV Community: Loïc Baumann

The 8-Byte Lock: Packing a Reader-Writer Lock Into 64 Bits

Loïc Baumann — Thu, 16 Jul 2026 14:01:20 +0000

💡Typhon is an embedded, persistent, ACID database engine written in .NET that speaks the native language of game servers and real-time simulations: entities, components, and systems.

It delivers full transactional safety with MVCC snapshot isolation at sub-microsecond latency, powered by cache-line-aware storage, zero-copy access, and configurable durability.

Series: A Database That Thinks Like a Game Engine

Why I'm Building a Database Engine in C#

What Game Engines Know About Data That Databases Forgot

Microsecond Latency in a Managed Language

Deadlock-Free by Construction

Three Durability Modes, One WAL

Building a Page Cache That Doesn't Count

MVCC at Microsecond Scale

The 8-Byte Lock (this post)

Why We Eliminated the Primary Key B+Tree (coming soon)

GitHub repo • 📬 Subscribe via RSS

A reader-writer lock has a lot to keep track of. How many readers are inside right now. How many are queued at the door. How many writers are queued behind them. Which thread, exactly, is holding it exclusively — because releasing a lock you don't own is a bug you want to catch loudly. Whether anyone has ever had to wait on it, so you can find your hot spots later.

In .NET the reflex answer is ReaderWriterLockSlim. It tracks all of that for you, and it costs you a heap object with a header, a sync block, an internal wait queue, and a call into the kernel when things get tense.

Typhon's answer is a ulong. All of it — the counter, the three classes of waiter, the owning thread id, the contention flag, the state machine — lives in eight bytes, and every state transition is exactly one CompareExchange. Uncontended, it costs 19 nanoseconds.

This post is the bit layout, the pattern that makes it readable instead of a swamp of shifts and masks, the fairness ladder that stops readers from starving writers, and an honest accounting of the parts I got wrong. And it ends on the trade that actually decides which lock goes where: every feature in that word is paid for in bits — and when the lock lives inside a page that gets written to disk, bits are a great deal more expensive than they look.

📍 Where we are

The last post built revision chains — the per-component version lists that give every transaction its own frozen snapshot of the database. Chains get appended to while other threads are walking them, so something has to arbitrate. I waved at it and moved on: "a small reader-writer lock in the header." This is that lock, and its smaller sibling.

And it connects to Deadlock-Free by Construction, which made a strong claim: Typhon has no deadlock detector because it holds no data locks across operations. That's still true. But "no data locks" doesn't mean "no locks" — it means the locks that remain are short, physical, and local: a latch on a page while you read its header, a latch on a chain while you splice a revision into it. Held for tens of nanoseconds, never across a wait, never two at once in an order that could cycle. Those latches are what this post is about, and their size is the whole design constraint.

🔒 Why not just use the lock in the box?

Steel-manning first: ReaderWriterLockSlim is a good general-purpose lock, and if you need a handful of them you should use it. The trouble is what "a handful" means here.

Typhon needs a latch on every page in the page cache. Every block chain in every allocator. Every archetype cluster. Every component table. That's not a handful — in a database with a few gigabytes resident, that's hundreds of thousands of locks, each one guarding a critical section that lasts about as long as a cache miss.

At that multiplicity, three things about the standard answer become disqualifying:

Allocation. Monitor inflates a sync block per object; the modern System.Threading.Lock that the lock statement now prefers is itself a class, and so is ReaderWriterLockSlim — a heap object with a header, plus internal wait-queue machinery. Whichever you pick, you get an object. But a lock that must be a field inside a page header, sitting in a memory-mapped file, cannot be an object at all. It has to be a value you can embed.

Size. Even if you could embed it, sixty-odd bytes of lock inside a page header you were trying to keep to a cache line is a non-starter. The lock has to be an incidental cost of the structure, not a dominant one.

The floor. Typhon's cost model has a hierarchy, each rung roughly ten times the last:

Level	What it is	Cost
0	Thread-local read	~2 ns
1	Uncontended atomic (CAS)	~5–10 ns
2	Contended atomic, true sharing	20–140 ns
3	System call	~500–1,000 ns
4	Context switch / blocking lock	~10,000 ns
5	Thread oversubscription	100,000+ ns

A lock that blocks is a lock that can cost you Level 4. Ten microseconds, to protect a critical section that was going to last fifty nanoseconds — a 200× overhead on the thing you were trying to make fast. In a database targeting microsecond transactions, that single fact drives the whole design: stay on rungs 1 and 2, never touch rung 4 if the work is short enough to spin through.

So the requirement is a lock that is a plain value type, small enough to embed by the hundred-thousand, that transitions with atomics and never enters the kernel on the happy path. Nothing in the box does that. You have to build it.

🧩 What fits in sixty-four bits

AccessControl is one field — private ulong _data — carved up like this:

//  8  Shared usage counter   (bits 0-7)     up to 255 concurrent readers
//  8  Shared waiters         (bits 8-15)
//  8  Exclusive waiters      (bits 16-23)
//  8  Promoter waiters       (bits 24-31)
// 16  Exclusive thread id    (bits 32-47)
//  1  Contention flag        (bit 48)       sticky
// 13  Reserved               (bits 49-61)
//  2  State                  (bits 62-63)   Idle | Shared | Exclusive

Two design choices in there are worth pulling out.

Three separate waiter counters, not one. Readers waiting, writers waiting, and promoters waiting (a promoter is a thread that already holds shared access and wants to upgrade to exclusive) each get their own byte. That looks like a luxury until you see what it buys, which is the next section.

A sticky contention bit. Bit 48 is set — with a single atomic OR — the first time any thread has to wait on this lock, and it's never cleared until Reset(). The fast path never reads it. It costs nothing to carry, and it means that at any later moment I can sweep every page in the cache and ask which of these locks has ever been contended, even once — a free, permanent, per-lock hot-spot map. It's the cheapest profiling I have anywhere in the engine: one bit, set at most once, read only by tooling.

🧵 Why the thread id is exactly sixteen bits

The owning thread gets sixteen bits, and the field earns its keep: releasing an exclusive lock you don't own is a protocol violation, and I want it to throw rather than quietly corrupt the word. But a fixed-width thread id invites the obvious question — what happens when you run out?

Nothing, and the reason is exactly why Environment.CurrentManagedThreadId exists separately from the OS thread id in the first place. The OS id is a sparse, opaque handle whose reuse is nobody's contract. The managed id is deliberately the opposite: the runtime hands out the lowest available number, and a dead thread's id goes straight back into the pool. Ids stay dense and small — they count the threads alive right now, not the threads that have ever existed.

That inverts the constraint, and it's the whole reason sixteen bits is enough. Monotonic ids would make the field a lifetime budget: hand out 65,535 of them over the life of the process and the next thread wraps into someone else's identity. Recycled ids make it a concurrency ceiling instead — 65,535 threads alive at the same instant. A server that churns through millions of threads over a week never moves that ceiling; it just keeps handing out the same low numbers. And 65,535 simultaneously-live threads inside an embedded database engine isn't a limit to design around, it's a diagnosis: if you're there, the lock word is the least of your problems.

(It started at ten bits, which was a mistake — 1,024 is fine on a laptop and nonsense on a 512-core server.)

⚠️ The dependency I'm taking on, stated out loud. Lowest-available reuse is what the open-source runtime does; it is not what the runtime promises. No specification obliges ManagedThreadId to stay dense. I'm relying on an implementation detail, on purpose, and the reason I sleep at night is that the property is load-bearing for everybody who indexes anything by thread id — which is a lot of code, including the runtime's own. The incentive to preserve it is enormous and the incentive to break it is zero. But an assumption you've reasoned about and written down is a design decision; the same assumption left implicit is a landmine. So: written down.

💎 The prettiest code in the engine

Here's the problem with packing a lock into a word: the code turns into a swamp. Every operation becomes shift-mask-or-shift-back, and one misplaced & is a corruption bug that shows up as a hang under load three weeks later.

The fix is LockData — a ref struct that makes the word behave like an object while still committing like a word:

private ref struct LockData
{
    private ref ulong _data;   // points at the real lock word, in place
    private ulong _initial;    // what we read
    private ulong _staging;    // what we're building

    public int SharedCounter
    {
        get => (int)(_staging & SharedCounterMask);
        set => _staging = (_staging & ~SharedCounterMask) | (uint)value;
    }

    public ulong State
    {
        get => _staging & StateMask;
        set => _staging = (_staging & ~StateMask) | value;
    }

    // ... SharedWaiters, ExclusiveWaiters, PromoterWaiters, ThreadId

    public bool TryUpdate()
    {
        var succeed = Interlocked.CompareExchange(ref _data, _staging, _initial) == _initial;
        if (!succeed) Fetch();      // someone beat us — re-read and let the caller retry
        return succeed;
    }
}

Now the actual lock logic reads like a state machine, because it is one:

case IdleState:
    if (ld.CanShareStart)
    {
        ld.State = SharedState;
        ld.SharedCounter = 1;
        break;                 // fall through to TryUpdate()
    }
    ...

Two fields assigned, and the whole thing publishes atomically. That's the trick, and it's the part I'd take to any other system: _staging is a local. Every one of those property setters is bit arithmetic on a value sitting in a register — no atomics, no memory barriers, no contention, because nobody else can see it. You mutate it as many times as you like, as legibly as you like, and pay for exactly one atomic operation at the end when TryUpdate publishes the finished word with a single CompareExchange.

A transition that touches four logical fields costs one CAS. Not four. And if it loses the race, Fetch() re-reads the word and the loop reassesses from the new reality — which is why every one of these operations is written as while (true) around a switch. Optimistic, retry-on-collision, no lock to take a lock.

The same file has one more trick worth stealing. Blocking calls take a refWaitContext carrying a deadline and a cancellation token — but most callers want to wait forever and shouldn't pay for the privilege. So they pass ref WaitContext.Null, and the struct checks once:

_isNullRef = Unsafe.IsNullRef(ref ctx);
// ...
public bool ShouldStop => !_isNullRef && _ctx.ShouldStop;

Unsafe.IsNullRef gives you a null reference rather than a nullable value: infinite wait costs one bool test, and the timeout machinery is genuinely absent rather than merely unused.

🪜 The fairness ladder

Now the payoff for those three waiter counters. The entire fairness policy of the lock is three one-line predicates:

public bool CanShareStart        => (_staging & (PromoterWaitersMask | ExclusiveWaitersMask)) == 0;
public bool CanExclusiveStart    => (_staging & PromoterWaitersMask) == 0;
public bool CanPromoteToExclusive => (_initial & SharedCounterMask) == 1;

Read them as a priority ladder — promoters beat writers beat readers:

A new reader may only enter if no writer and no promoter is waiting. This is the anti-starvation rule. Under a heavy read load, a reader-preferring lock lets an endless stream of readers hold the door open forever and a writer waits until the workload changes. (This is the documented default behaviour of ReaderWriterLockSlim.) Here, the instant one writer registers, the reader gate slams: incoming readers queue behind it, the in-flight readers drain, the writer goes.
A new writer stands down for promoters, because a promoter is a thread already holding shared access. Making it wait behind a fresh writer would be perverse — it's already inside.
A promoter may only upgrade when it is the sole reader (counter == 1). Two threads both holding shared access and both trying to upgrade is the textbook promotion deadlock; the counter makes it structurally unrepresentable, because at most one of them can ever see a count of one.

Three masks, one comparison each. No queue, no condition variable, no priority-inheritance logic — a complete fairness policy expressed as "are these bytes zero."

🤏 Four bytes, and what they cost you

Everything above — the waiter counters, the fairness ladder, the explicit state field — is features, and every feature in that word is paid for in bits. So there's a second lock, AccessControlSmall, which spends half as many:

// 15  Shared counter   (bits 0-14, max 32,767)
//  1  Contention flag  (bit 15)
// 16  Thread id        (bits 16-31)

Notice what's missing. There is no state field. State is implied — a non-zero thread id means Exclusive, a non-zero counter means Shared, both zero means Idle. Which has a lovely consequence: the Idle → Exclusive transition, the most common one there is, becomes a single CAS against literal zero.

Also missing: all three waiter counters. And that is the trade, stated plainly — AccessControlSmall has no waiter tracking, therefore no fairness. A pending writer can be starved by a sustained stream of readers. Nothing clever recovers that; you either need the counters or you don't.

So which lock goes where is a straight exchange of features against bytes — and the reason bytes are worth so much more than they look is that some of these locks are not merely in memory. They're in the data.

A latch in a page header lives inside a page that gets written to disk. It is persistent state. Those four-versus-eight bytes are not a transient cost you can buy your way out of with more RAM — they are written on every flush, read back on every load, and they occupy space in the page that would otherwise be holding your data, in every page, for the life of the database. Multiply by a few million pages and the difference stops being an implementation detail and starts being a storage-format decision, which is the kind of decision you don't get to revisit later.

That reframes the whole question. It isn't "smaller is better" — it's that the byte budget of a persistent structure is nothing like the byte budget of a heap object. So the rule is simply: on a structure that's central, in-memory, long-lived and genuinely contended, fairness is worth eight bytes and you take the full lock. On a structure that gets serialized into a page, you take the four-byte one, spend the savings on data, and keep the critical sections short enough that starvation never has the time to develop.

📊 The numbers

Measured with BenchmarkDotNet on an Intel Xeon Platinum 8151 @ 3.40 GHz, Ubuntu 22.04, .NET 10. Each figure is a full acquire and release, single-threaded, with nobody to fight:

Operation	`AccessControl` (8 B)	`AccessControlSmall` (4 B)
Shared: acquire + release	18.8 ns	17.0 ns
Exclusive: acquire + release	21.5 ns	24.5 ns
Promote shared → exclusive → demote	44 ns	45.5 ns

That's the floor, and it is Level 1 of the hierarchy: a CompareExchange on a line already sitting in this core's L1, with no other core wanting it.

Now the opposite extreme — the same shared acquire/release, but with N−1 background threads hammering the same lock word in a tight loop:

Threads contending	Shared: acquire + release
2	940 ns
4	1.86 µs
8	2.00 µs

Fifty to a hundredfold. Nothing about the lock changed between those two tables — same word, same instructions, same code path. The only difference is that the cache line is now being dragged from core to core on every attempt.

I want to be precise about what that second table is, though, because it would be easy to read it as a warning about Typhon and it isn't one. It's a hardware number, not an engine number. It's what a contended CAS costs, obtained by constructing the worst case deliberately: many threads, one word, no work in between. And the engine is built so that scenario doesn't arise.

There is no central lock in Typhon — no handful of monitors that every operation funnels through. There are hundreds of thousands of latches: one per page, per component table, per cluster, per block chain, each held for the tens of nanoseconds it takes to read a header or splice a pointer. For that table to describe the engine, a crowd of threads would have to want the same latch at the same instant. At this granularity, with hold times this short, that is close to a non-event. Not impossible — "almost never" isn't "never" — but it is nowhere near the steady state the benchmark manufactures.

So read that second table as a receipt rather than a warning: it's the bill you'd be handed for centralising your locking, and it's why Typhon doesn't. The answer to contention was never a cleverer lock — it's granularity. Don't make one lock hot; make a hundred thousand cold ones.

⚖️ Trade-offs, and what I got wrong

I nearly went hunting for three nanoseconds that were never there. The 4-byte lock measures slower at exclusive acquisition than the 8-byte one — 24.5 ns against 21.5 — which is the opposite of what its simpler fast path predicts, and I spent a while looking for the flaw in the compact design. There is no flaw. Every field read, every mask, every shift in both locks is register arithmetic, and register arithmetic is free: the entire price of the operation is the Interlocked. And a CAS has no fixed price, only a price in a context — the memory system decides what the line costs, not your bit fields. My bet is that the smaller struct is likelier to share its line with whatever sits beside it, so its CAS pays coherence traffic the other's doesn't. I have no proof and won't pretend otherwise. But a three-nanosecond spread between two locks was never going to be a fact about the locks.

I shrink the lock to 4 bytes and then pad it back to 64. In ArchetypeClusterState the latch is wrapped in a [StructLayout(Size = 64)] struct so it owns an entire cache line — it sits beside hot mutable counters, and false sharing on a lock word is worse than a big lock word. Two threads taking two logically independent locks that happen to share a line will ping-pong it between cores on every CAS, at full contended cost, having never contended for anything; the engine's spatial rules go so far as to forbid bit-packed latch arrays for exactly that reason. So the honest summary of the size story is not "smaller is better." It's: make the lock small enough to live where the data lives, then spend whatever padding it takes to keep its line to itself.

"Zero-cost telemetry" is very nearly true, and I should stop saying "zero." Every acquire and release has a trace-event emit call, gated on a static readonly bool so the JIT can prove the branch dead and delete it. It works — but the off-path benchmark still shows roughly 2 ns per iteration surviving versus an empty method. Two nanoseconds on a 19 ns operation is about 10%, and calling that "free" would be exactly the kind of claim I'd disbelieve in someone else's post.

🎯 The takeaway

The reusable idea isn't the bit layout — yours will be different. It's the staging pattern: read the whole word once, mutate a local copy as many times and as legibly as you want, publish it with one CompareExchange, and retry from the top if you lost.

That structure is what lets you have both of the things people assume are in tension. The lock's state can be arbitrarily rich — five fields, a state machine, a fairness ladder, a diagnostic bit — because manipulating it is just arithmetic on a register that no other thread can see. And it can still be atomic, because "atomic" is a property of the single instruction that publishes the result, not of the reasoning that produced it.

Which leaves exactly one thing that costs anything: the publish. Not the shifts, not the masks, not how many fields you touched on the way — one CompareExchange, and a price set entirely by the state of the cache line it lands on. So the design lever that matters was never what you put in the word. It's where the word lives. Pack it as densely and as cleverly as you like; then go make sure nothing else is touching its line.

Whenever you find yourself reaching for a lock to protect a small piece of state, ask whether the state could be the word instead. Often it fits. And when it fits, the lock stops being an object you acquire and becomes a number you agree on.

⏭️ What's next

This whole post has been about making a latch cost as little as it possibly can. The next one is about the cheaper move — not having the structure at all. Typhon used to carry a primary-key B+Tree, for the very best of reasons: every database has a primary index. That's simply what one does. It turned out to be a reflex imported from a world this engine doesn't live in, because an ECS entity is found by its archetype and its key — it was never going to be walked to through an index. So the whole thing came out. Post #9: Why We Eliminated the Primary Key B+Tree — what it cost to keep, what replaced it, and how to spot the moment you've inherited an assumption instead of making a decision.

Follow the GitHub repo for source and benchmarks, or subscribe via RSS.

MVCC at Microsecond Scale: Snapshot Isolation Without Cloning Rows

Loïc Baumann — Fri, 03 Jul 2026 12:55:50 +0000

💡Typhon is an embedded, persistent, ACID database engine written in .NET that speaks the native language of game servers and real-time simulations: entities, components, and systems.

It delivers full transactional safety with MVCC snapshot isolation at sub-microsecond latency, powered by cache-line-aware storage, zero-copy access, and configurable durability.

Series: A Database That Thinks Like a Game Engine

Why I'm Building a Database Engine in C#

What Game Engines Know About Data That Databases Forgot

Microsecond Latency in a Managed Language

Deadlock-Free by Construction

Three Durability Modes, One WAL

Building a Page Cache That Doesn't Count

MVCC at Microsecond Scale (this post)

The 8-Byte Lock (coming soon)

GitHub repo • 📬 Subscribe via RSS

An entity has a position, a velocity, a health bar, a level, a name, a team, a score, and a bag of status flags — eight components. A hit lands and its health drops by three. In a textbook MVCC database, that one-field write produces a brand-new copy of all eight. The position it didn't move, the name it didn't change, the flags it didn't touch — copied, re-indexed, and left behind as garbage for a vacuum process to sweep up later.

Typhon writes one revision. Just the health. The other seven components don't know anything happened. This post is about the data structure that makes that possible, the one-byte rule that decides what each transaction is allowed to see, and why a read stays fast and nearly flat whether the value changed once or fifty times.

🛡️ Why I gave Typhon one isolation level, not five. Every SQL engine hands you a dial — SQL Server has five levels, from read uncommitted to serializable, each leaking different anomalies (dirty reads, phantoms, and friends). Picking wrong is a bug that surfaces only under production load. That dial exists because in a lock-based engine, stronger isolation means more locking means less concurrency — so the weak levels are escape hatches for when locks hurt. MVCC deletes the tradeoff: readers never lock, writers append instead of overwriting, so the strong guarantee is also the fast one. Nothing to buy back, so there's no dial — one model, always on: snapshot isolation, the database frozen the instant your transaction began. When two transactions collide on the same component, it isn't silently dropped — it's reconciled at commit (see Trade-offs). Simple to reason about, hard to misuse.

📍 Where we are

Two earlier posts set this one up. Deadlock-Free by Construction argued that Typhon has no deadlock detector because it holds no data locks — and the first of the three pillars holding that claim up was MVCC: readers see an immutable snapshot, writers append new revisions, nobody waits on anybody. That post promised a drill-down. This is it.

Building a Page Cache That Doesn't Count is the other half of the foundation. Those epoch-stamped 8 KB pages are exactly where revision chains live, and the trick that retires an old revision once no transaction can still see it is the same grace-period reasoning that retires an evictable page. If you read that post, you already understand Typhon's garbage collector — you just haven't seen it applied to versions yet.

The contract MVCC has to honour is snapshot isolation: a transaction picks a point in time when it starts and sees the whole database frozen at that instant for its entire lifetime — no dirty reads, no phantoms, later commits invisible. The question every MVCC implementation answers differently is: what do you physically store so that many transactions can each see a different "now" of the same data at the same time?

🧬 The row-cloning tax

The classic answer, the one PostgreSQL uses, is tuple versioning. A row is a tuple. Update any column and you write a new version of the entire tuple, chained to the old one by a pointer, each stamped with the transaction IDs that bound its visibility. Readers walk the version chain and pick the tuple their snapshot is allowed to see.

It's a proven design, and for a row of three ints it's perfectly fine. The tax shows up when rows are wide and updates are narrow — which is precisely the shape of an entity-component workload. A simulation tick nudges one field on thousands of entities: health here, position there. Every one of those single-field writes clones a whole wide row. You pay to copy columns that didn't change, you pay to re-point the secondary indexes at the new tuple, and you pay a third time when a background vacuum comes through to reclaim the corpses. The write amplification is proportional to how wide the row is, when it should be proportional to how much you changed.

⛓️ Per-component revision chains

Typhon never has a "row" to clone, because it doesn't store rows. It stores components in separate columnar tables — that's the ECS design an earlier post was about. MVCC then attaches to the natural unit: each component of each entity owns its own revision chain. Update health, and you append one entry to that entity's health chain. The position chain, the name chain, the other five — untouched, because from their point of view nothing changed. An eight-component entity that updates one component creates one revision, not eight. That's the whole headline, and it falls straight out of storing columns instead of rows.

A chain entry is deliberately tiny — 12 bytes, because layout density decides how many entries fit in a cache-line-sized chunk:

[StructLayout(LayoutKind.Sequential, Pack = 2)]
internal struct CompRevStorageElement
{
    public int    ComponentChunkId;   // 0 = tombstone (a delete)
    private uint   _packedTickHigh;    // TSN bits 16..47
    private ushort _packedTickLow;     // TSN bits  0..15
    private ushort _packedUowId;       // UowId in bits 0..14, IsolationFlag in bit 15
}

Four fields, no waste. ComponentChunkId points at the actual component payload elsewhere in the page cache (0 is the sentinel for a tombstone — a delete). The Transaction Sequence Number — the global clock every snapshot reads from — is a 48-bit value split across a uint and a ushort; 48 bits is 280 trillion transactions, which is enough. The last ushort does double duty: 15 bits of UowId (which unit of work wrote this) and, in its top bit, the single most important flag in the whole system — IsolationFlag.

Why 12 bytes and not 16? Because the chain lives in 64-byte chunks, and 64 bytes is one cache line. The root chunk spends 28 bytes on a header — a small reader-writer lock, chain bookkeeping, the entity key — leaving 36 bytes, which is exactly three 12-byte entries. Overflow chunks carry only a 4-byte "next chunk" pointer, leaving 60 bytes: exactly five entries. One byte more per entry and that arithmetic turns wasteful — you'd fit two per root chunk and burn the rest as padding. The struct is sized backward from the cache line.

👁️ Visibility: two facts, one byte

Given a chain, a read has to answer one question: of all these versions, which one is this transaction allowed to see? The answer is two facts about each entry, and the second is that top bit.

💡 What's a TSN? The Transaction Sequence Number is Typhon's logical clock — one global counter that only ever ticks up. Every transaction draws a number from it at the moment it starts, and that number does double duty: it's the transaction's snapshot (the single "now" it will see for its entire life) and it's the stamp burned onto any revision the transaction writes. Because the counter is monotonic, comparing two TSNs is just asking which happened first — and that comparison is the whole basis for deciding what a snapshot is allowed to see.

The first fact is chronology. Every entry carries the TSN of the transaction that wrote it; every reader carries the TSN it froze at when it started. An entry is a candidate only if entry.TSN <= reader.TSN — you can see the past, never the future.

The second fact is committedness, and it's the IsolationFlag. When a writer appends an entry, it sets the flag to true: written, but not yet committed. That entry is invisible to every other reader regardless of its TSN, until the writer commits and clears the flag. This is the piece pure chronology can't express. A reader whose snapshot sits at TSN 190 is chronologically entitled to see an entry stamped 180 — but if that entry is still mid-flight with its flag up, the reader must skip it and fall back to the last committed version underneath.

So visibility is committed AND TSN <= snapshot, and the whole outcome of a walk compresses into a one-byte enum — the entire MVCC contract distilled to four states:

public enum RevisionReadStatus : byte
{
    Success           = 0,  // a visible revision was found — here's its payload chunk
    NotFound          = 1,  // this entity never had a chain for this component
    SnapshotInvisible = 2,  // the chain exists, but nothing is visible at our snapshot
    Deleted           = 3,  // the visible revision is a tombstone
}

That Deleted state is quietly powerful. A tombstone is a real revision with a real TSN — it just points at chunk 0. A transaction whose snapshot predates the delete walks right past the tombstone and reads the entity's pre-delete content, which is still sitting on the chain. You get time-travel reads of deleted entities for free, for as long as the old versions survive — and how long they survive is the garbage-collection story below.

One honest caveat on the walk itself. You might expect it to stop at the first entry past the snapshot, binary-search style. It can't — the chain isn't sorted by TSN, and the reason is concurrency. The walk resolves "latest committed version" by keeping the last visible entry it passes, so entries have to sit in commit order. But commit order and TSN order slightly diverge: a transaction created earlier (a lower TSN) can commit later than one created after it, and when it does, its revision is moved to the tail of the chain — landing physically after a higher-TSN entry that already committed. So a later slot can legitimately hold an older TSN, and the walk has to scan the whole live chain rather than break early. It stays cheap only because that chain is short — the grace-period cleanup keeps it to a handful of entries.

✍️ The write path, and a decision I'd defend

A write appends. It takes the chain's lock in exclusive mode, grows the chain by one overflow chunk if the current one is full, allocates a payload chunk for the new component value (or writes 0 for a delete), and stamps a fresh entry: TSN, UowId, ComponentChunkId, IsolationFlag = true. Then it releases the lock. The writer can now see its own change — not by walking the chain, which would skip its own flagged entry, but through a small transaction-local cache that remembers "the chunk I just wrote." Every other reader still lands on the previous committed version. At commit, the only thing the revision layer does is flip that one bit from true to false. The entry becomes visible atomically, to everyone, in a single flag write.

💡 And the UowId? If the TSN says when a revision was written, the Unit-of-Work ID says who wrote it — which unit of work produced it. It deliberately stays off the read path: WalkChain decides visibility from the TSN and the IsolationFlag alone and never consults a UowId. Its work happens to the side — it lets a concurrent cleanup pass know whose in-flight chunks it must not reclaim, lets commit-time conflict detection name the other writer, and gives crash recovery the bookkeeping it needs to rebuild only the revisions that were durably committed. (That last one is settled before the engine serves a single read — recovery replays the WAL and scrubs anything a crash left half-written, so a live reader can never trip over it.) Temporal order is the TSN's job; ownership — and a clean slate after a crash — is the UowId's.

Here's the decision worth pausing on, because the obvious alternative is wrong in an instructive way. That UowId — the identity of the writing unit of work — is stamped when the entry is written, not in a loop at commit time. The tidy-sounding version ("commit walks everything the transaction touched and stamps ownership then") was rejected, for reasons that only surface once you look at what else is happening concurrently:

Cleanup runs against live, uncommitted chains. A garbage-collection pass on another thread has to know "an active transaction owns this entry, don't touch the chunk it points at" — and it reads exactly the flag and the UowId to know that. Both must be present the instant the entry exists, not eventually.
Conflict detection at commit reads the UowId to identify the other writer. If ownership were only assigned at commit, a transaction committing while another's write is in flight would be trying to read an identity that hasn't been written yet — a chicken-and-egg you don't want on the commit hot path.

So commit stays a single flag flip instead of a chain walk over hundreds of touched components. The cost of that simplicity is one field written a few microseconds earlier than strictly necessary. Cheap.

📊 The numbers

So what does versioning actually cost? These are measured per-operation numbers — Ryzen 9 7950X, .NET 10, Release, steady-state with a hot cache — for the identical component laid out three ways:

Per-entity operation	Versioned (MVCC)	SingleVersion	Transient
Read	~80 ns	~15 ns	~15 ns
Write	~250 ns	~40 ns	~40 ns

Two things jump out. First, SingleVersion and Transient cost the same — both are pointer arithmetic into a pinned page and a cache-line access; whether that page is memory-mapped or heap-backed is invisible once it's in L1. Second, the cliff is MVCC: a Versioned read runs ~5× a raw read, a Versioned write ~6×. The lever is that the mode is chosen per component — a hot, history-less field like a cached AI cost or an animation tween can opt out of versioning and run at ~15 ns.

That 6× on writes is the whole thesis showing up in a profiler. A SingleVersion write is a store into a slot. A Versioned write is copy-on-write — allocate a fresh content chunk, copy the current value into it, append a revision entry pointing at it, take the chain lock, and stamp a TSN and UowId. (The WAL record and the eventual GC of the version it replaced are real costs too, but they're paid at commit and in the background — not inside that 250 ns.) It's the same building blocks as the SingleVersion path, just a lot more of them. That isn't a missed optimization; it's what snapshot isolation physically is. You pay ~80 ns to read a value nobody can tear out from under you, and ~250 ns to write one without ever blocking a reader.

What the per-op numbers don't show is chain depth. A read walks the live chain with no early exit, so its cost grows with the number of live revisions it has to pass. In steady state that's a non-issue — grace-period cleanup keeps the live chain to a handful of entries, so you stay near that ~80 ns. It only bites if you let a chain grow: aim a burst of concurrent writers at one hot entity and its chain lengthens until they drain, and the walk lengthens with it. Bounded contention plus cleanup keeps you in the flat regime.

That cleanup is the page-cache grace period again, wearing a different hat. A revision is dead once no live transaction's snapshot could still select it — i.e. once its TSN falls below the oldest active transaction's TSN. When that threshold advances, cleanup compacts the chain: it drops the dead entries, keeps one committed "sentinel" so a reader sitting exactly at the boundary still has its baseline, and never touches an entry whose IsolationFlag is still up. No separate vacuum daemon, no scheduled sweep — reclamation is driven entirely by the oldest reader finishing, exactly as page eviction waits for the oldest epoch to retire.

💎 The prettiest code in the engine

There's a sibling problem that a full revision chain would be absurd overkill for. Every entity has an EnabledBits mask — 16 bits marking which of its components are logically "on" (present in storage but toggled out of queries). Toggling a component is a common, cheap operation. But it still has to obey snapshot isolation: a transaction that started before you disabled a component must keep seeing it enabled.

Sixteen bits do not deserve a chain of 64-byte chunks. So the fast path is the entire mechanism most of the time:

public ushort ResolveEnabledBits(long entityKey, ushort inlineBits, long txTsn)
{
    if (_overrideCount == 0) return inlineBits;   // fast path: no toggles in flight, done
    if (!_overrides.TryGetValue(entityKey, out var history)) return inlineBits;
    return history.ResolveAt(txTsn, inlineBits);
}

The current bits live inline on the entity record. The moment a toggle commits while an older transaction is still running, the pre-change bits get parked in an override dictionary keyed by entity, tagged with the TSN of the change. A reader only consults that dictionary when _overrideCount says overrides exist at all — and then ResolveAt walks the tiny per-entity history newest-to-oldest and hands back the bits that were current at the reader's snapshot. When the last transaction old enough to care finishes, the pruner drops the entry and _overrideCount falls back toward zero. The dictionary is empty in the overwhelmingly common case, so the whole apparatus costs one integer comparison. It's MVCC without a chain — versioning made proportional to how expensive the thing being versioned actually is. That principle, don't pay chain overhead for something that fits in a register, is the one I'd take to any system.

⚖️ Trade-offs

Two costs, stated plainly.

Write-write conflicts are resolved, not rejected. Two transactions writing the same component never block during execution — Typhon holds no data locks while one runs — and, contrary to what "optimistic" usually implies, they don't abort or retry either. The collision is resolved when the second commits. Most components have a single writer, so conflicts are rare; when one fires, the default is last-writer-wins — fine for a position, a footgun for an accumulator like a gold balance, where a blind overwrite discards real work. So Commit takes an optional conflict handler: on a conflict the engine hands you the read, committed, and committing values — once per entity, atomically under that entity's chain lock — and you decide: keep yours, take theirs, revert, or merge (rebase the delta, clamp, sum). The real cost isn't aborts or retries; it's having to think about the merge — the default drops writes silently, and the handler runs in a tight context (fast, no I/O, no re-entering the engine) with no built-in roll-back.

Time travel has rent. Those readable-after-delete tombstones, and the old versions they shade, occupy pages until the oldest transaction that might want them finishes. A single long-lived reader holds the cleanup threshold down and lets chains and tombstones accumulate behind it — the versioning equivalent of the working-set pressure the page-cache post described. Bounded transactions keep it healthy; a forgotten long one is how you get bloat.

🎯 The takeaway

The reusable idea isn't "chains" or "snapshots" — every MVCC system has those. It's match the versioned unit to the thing that actually changes. Row-versioning copies the whole row because the row is the unit it stores. Store columns instead and the unit shrinks to the component, so a write costs what it changed and nothing more — and a 16-bit mask shrinks further still, to a dictionary that's empty until two snapshots actually disagree.

Whatever you're versioning — rows, documents, config, undo history — ask the question the page cache asked before it reached for a counter: what is the smallest unit I actually have to keep a history of? Version that, and only that.

⏭️ What's next

Every revision chain in this post was guarded by a lock I waved at as "a small reader-writer lock in the header." That lock is four bytes. It packs a full shared/exclusive lock — reader count, writer bit, waiter tracking, an owning thread id — into a single 32-bit word, and its bigger sibling does the same in 64 bits with room for three access modes. Post #8: The 8-Byte Lock — packing a reader-writer lock into a handful of bytes, and why the thread id inside it is exactly 16 bits wide.

Follow the GitHub repo for source and benchmarks, or subscribe via RSS.

Building a Page Cache That Doesn't Count: Epoch-Based Memory Management

Loïc Baumann — Fri, 26 Jun 2026 15:23:52 +0000

💡Typhon is an embedded, persistent, ACID database engine written in .NET that speaks the native language of game servers and real-time simulations: entities, components, and systems.

It delivers full transactional safety with MVCC snapshot isolation at sub-microsecond latency, powered by cache-line-aware storage, zero-copy access, and configurable durability.

Series: A Database That Thinks Like a Game Engine

Why I'm Building a Database Engine in C#

What Game Engines Know About Data That Databases Forgot

Microsecond Latency in a Managed Language

Deadlock-Free by Construction

Three Durability Modes, One WAL

Building a Page Cache That Doesn't Count (this post)

MVCC at Microsecond Scale (coming soon)

GitHub repo • 📬 Subscribe via RSS

A transaction that reads a thousand pages should pay for reading a thousand pages. Mine used to pay for two thousand atomic operations on top — one to pin each page so the cache wouldn't yank it out from under a live pointer, one to unpin it afterward — before a single byte of useful work happened.

That bookkeeping was pure tax. Worse, it was contended tax. The page cache in Typhon today touches those same thousand pages and pays for exactly two operations, flat, regardless of the count. This post is about how the counter went away — and the one corner where I had to bring a smaller one back.

📍 Where we are

A quick recap for anyone joining mid-series. Typhon stores everything — components, indexes, the lot — in 8 KB pages. Those pages are cached in a single byte[] that is pinned with a GCHandle so the GC can never move it. Pinning is what makes the rest of the engine possible: once the backing array is fixed in memory, the hot paths hand out raw pointers and ref T interior references straight into the cache slot. No copy, no marshaling, no managed wrapper. A read of a component is a pointer add and a dereference.

That zero-copy guarantee is also the whole problem. The cache is finite — 256 pages by default — so when it fills, a clock-sweep eviction picks a victim slot and reuses it for a different file page. If a reader is still holding a ref Position into that slot when the sweep recycles it, the reader is now looking at someone else's data. A use-after-free, in a managed language, with no exception to tell you it happened — just a silently wrong number.

So the cache needs a lifetime rule: a slot must not be evicted while anyone still holds a pointer into it. The interesting part is not that rule. Every cache has it. The interesting part is what you pay to enforce it.

🧾 The obvious answer, and its bill

The textbook enforcement is reference counting. Every page carries a counter. You take a reference (++) before you read, you drop it (--) when you're done, and eviction skips any page whose count is above zero. Simple, correct, and the first thing I shipped — Typhon's early page cache had exactly this, a per-page ConcurrentSharedCounter.

It has three costs, and they compound:

It's 2N. A transaction that touches N pages does N increments and N decrements. The work scales with the data, which is the opposite of what you want from bookkeeping.
The decrement is mandatory and paired. Every acquire needs its matching release on every exit path, including exceptions. Miss one and the page is pinned forever — a slow leak that strands cache slots until the engine wedges. This is the half that generates bugs.
The counter is shared, mutable, cross-core state. That ++/-- is an Interlocked operation — an atomic read-modify-write. When two worker threads touch the same hot page — a B+Tree root, say — its counter's cache line ping-pongs between their cores. The atomic instruction isn't the expensive part; the coherency traffic is. A contended counter can cost an order of magnitude more than an uncontended one, and the hottest pages are exactly the ones every thread wants.
It clutters everything it touches. A mandatory paired release means scaffolding at every call site — hundreds of using blocks whose entire reason to exist is a Dispose that decrements a counter. And the moment that overhead shows up in a profile, you start bending the code to dodge it: paths that steal an already-held reference instead of taking a fresh one, so an increment here cancels a decrement there. Each of those tricks is correct only under assumptions the next reader can't see from the call site. The counter didn't just cost cycles — it spread through the codebase and made the whole engine harder to reason about. That cost is invisible in a microbenchmark and very visible six months later.

Reference counting answers a question the cache never actually asked: "exactly how many people are looking at this page right now?" Eviction doesn't need that number. It needs a cheaper, weaker fact: "is it safe to reclaim this slot yet?" Those are different questions, and the second one has a much cheaper answer.

⏱️ The reframe: stop counting, start timing

The technique is epoch-based reclamation (EBR) — the same family of idea behind RCU in the Linux kernel. Instead of tracking who holds what, you track time, coarsely, and you only reclaim memory once enough time has passed that nobody could still be holding the old version.

💡 The intuition. Think of a museum that wants to renovate a gallery — but only once every visitor who might still be wandering through it has gone home. The expensive way is to tag each visitor and constantly track which gallery they're standing in; that's reference counting. The cheap way: stamp every visitor at the entrance with the hour they arrived, and have each gallery note the last hour anyone walked through it. Now the renovation crew checks a single number — the arrival time of the earliest visitor still in the building. Any gallery whose last visit predates that time is guaranteed empty of anyone who could still be inside, so the crew can move in. No per-visitor ledger, just one question: who's the oldest person still here? Epoch-based reclamation is that museum — the visitor's arrival stamp is the epoch a thread pins on entry, the gallery's last-walked hour is the page's stamp, and "the earliest visitor still inside" is the threshold eviction compares against.

"Time" here is a single global counter — the epoch — that ticks forward. The protocol has three moves:

Enter. When a thread starts a unit of work, it publishes the current epoch into a slot of its own: "I am active, and I started at epoch E."
Stamp. Every page the thread touches gets tagged with the current epoch — fire-and-forget, no matching release.
Exit. When the thread finishes, it clears its slot and ticks the global epoch forward by one.

Eviction then asks one question of a page: is its stamp older than the oldest still-active thread? If every active thread started after this page was last touched, no one can be holding a pointer into it, and the slot is free to recycle. That comparison is the entire safety check.

The asymmetry is the whole win. The expensive, bug-prone, contended half of reference counting — the mandatory paired release on every page — disappears entirely. Releasing is now a single global tick that retires all of a transaction's pages at once. What's left on the acquire side is a stamp that is uncontended and usually a no-op.

⚙️ How it actually works

Three types carry the design (src/Typhon.Engine/Foundation/Concurrency/internals/):

EpochManager — one per engine. Owns the global epoch counter and the thread registry.
EpochGuard — a ref struct RAII scope. Enter on construction, advance the epoch on the outermost exit. Being a ref struct, it can't escape to the heap or get boxed; it has to live on the stack and be disposed.
EpochThreadRegistry — a fixed array of per-thread slots holding each thread's pinned epoch.

A transaction wraps its whole lifetime in one guard:

// Managed by Transaction — one scope per unit of work
using var guard = EpochGuard.Enter(epochManager);

// Every page access inside this scope is protected, no per-page bookkeeping
pmmf.RequestPageEpoch(filePageIndex, epochManager.GlobalEpoch, out int memPageIndex);
byte* addr = pmmf.GetMemPageAddress(memPageIndex);
// ... read/write through raw pointers, hold ref T across many pages ...

Entering publishes the epoch into the thread's own slot. The hot path is a single write to thread-local memory — no atomic, no contention:

// EpochThreadRegistry.PinCurrentThread — outermost scope pins, nesting is free
var depth = _slots[slot].Depth;
_slots[slot].Depth = depth + 1;
if (depth == 0)
    _slots[slot].PinnedEpoch = epoch;   // publish: "active, started at this epoch"
return depth;

Stamping a page is an atomic-max — never let a page's stamp go backward — that skips the atomic write entirely in the common case where the page is already current for this epoch:

// PagedMMF.RequestPageEpoch — tag the page, never moving the stamp backward
long existing;
do
{
    existing = pi.AccessEpoch;
    if (currentEpoch <= existing)
        break;                  // already protected this epoch — no write at all
} while (Interlocked.CompareExchange(ref pi.AccessEpoch, currentEpoch, existing) != existing);

That Interlocked.CompareExchange is a compare-and-swap (CAS): it stores the new epoch only if the field still holds the value we just read, so two threads stamping the same page can't clobber each other. The first touch of a page in an epoch does one such CAS; every subsequent touch breaks out at the currentEpoch <= existing guard — a plain read and a compare, no atomic at all. And — this is the point — there is no release. Nothing to pair, nothing to forget, nothing to run in a finally.

Exiting the outermost scope is where the single shared atomic lives — the global epoch tick:

// EpochManager.ExitScope — outermost exit retires the whole transaction's pages
internal void ExitScope(int expectedDepth)
{
    if (_registry.UnpinCurrentThread(expectedDepth))
    {
        var newEpoch = Interlocked.Increment(ref _globalEpoch);
        TyphonEvent.EmitConcurrencyEpochAdvance((uint)newEpoch);
    }
}

And eviction is the comparison the whole scheme exists to make cheap. MinActiveEpoch is the smallest epoch any thread is still pinned to; a page survives if its stamp is at least that:

// PagedMMF.TryAcquire — the eviction guard, minus the dirty/in-flight checks
if (info.AccessEpoch >= minActiveEpoch)
    return false;   // a transaction old enough to hold a pointer is still live — skip

Walk the invariant once and it clicks. A thread that pinned epoch E contributes E to MinActiveEpoch, so MinActiveEpoch ≤ E. Any page it stamped was stamped at the global epoch at access time, which is ≥ E. So while that thread is live, every page it ever touched satisfies AccessEpoch ≥ E ≥ MinActiveEpoch and cannot be evicted. The moment it exits — and no older thread remains — MinActiveEpoch climbs past those stamps and they all become reclaimable together. This is a grace period, exactly as in RCU: reclamation waits until every reader that could have seen the old state has gone away.

📊 The numbers

Measured with BenchmarkDotNet on a Ryzen 9 7950X (Zen 4), .NET 10, RELEASE:

Operation	Cost	Allocations
`EpochGuard` enter + exit (incl. global tick)	3.5 ns	0
Three-level nested enter/exit	8.8 ns	0
`MinActiveEpoch` (eviction check, no threads pinned)	0.8 ns	0
`MinActiveEpoch` while a thread is pinned	6.6 ns	0
Page-cache hit (`RequestPageEpoch`, slot resident)	6.5 ns	0

The number that matters is the first one: 3.5 ns for a transaction's entire eviction-protection obligation, and it does not move when the page count goes up. A transaction touching one page and a transaction touching ten thousand pay the same 3.5 ns of protection overhead. The per-page stamps on top are uncontended and frequently free; the contended, paired, O(N) release is gone.

Put that against the model it replaced: a thousand-page transaction was a thousand Interlocked increments and a thousand decrements, on a thousand separate counters, several of them hot enough to bounce across cores on every touch. Trading 2,000 contended atomics for one global tick is the kind of win you only get by answering an easier question.

⚖️ Trade-offs, and the one place pure epochs weren't enough

Epoch protection is conservative — that's the source of both its speed and its cost. It doesn't know which pages a transaction is done with; it only knows the transaction is still running. So a transaction pins every page it has ever touched for its entire lifetime, whether it still needs them or not.

For short transactions that's exactly right and basically free. For a long one it bites: if a single transaction's working set grows past the cache size, every page it has stamped is epoch-protected, so eviction has no legal victim. The cache can't make room, and AllocateMemoryPage runs into a backpressure wall and eventually times out. Reference counting wouldn't have this problem — it could evict a page the long transaction had touched and released. Epochs can't, because there is no "released" until the scope exits. That working-set-fits-in-cache constraint is a real, documented limit of the design, not a bug I haven't gotten to.

The mitigation is to let a long-lived thread refresh its epoch mid-flight — advance its own pin without unpinning — so pages it touched earlier age out and become evictable while it keeps running:

// EpochManager.RefreshScope — stay continuously pinned, but move forward in time
var newEpoch = Interlocked.Increment(ref _globalEpoch);
_registry.RefreshPinnedEpoch(newEpoch);   // no unpinned window; MinActiveEpoch never gaps

Which is where the pure model sprang a leak. The whole premise is that a page is safe as long as its epoch is live. But a caller can hold a raw ref T into a page across a refresh — and a refresh deliberately ages that page out, marking it evictable while the pointer is still on the stack. The coarse epoch clock can't see a pointer that outlives the epoch that created it.

So pure EBR wasn't quite enough, and I had to bring back a small, targeted counter: SlotRefCount. It tracks the much narrower fact of "a live accessor slot is pointing at this page right now," and it gates eviction alongside the epoch check. The full guard is the conjunction:

// Evict only when nobody can be looking — by epoch OR by raw pointer
(DirtyCounter == 0) && (AccessEpoch < MinActiveEpoch) && (SlotRefCount == 0)

It would be tidier to say I deleted reference counting outright. The honest version is that I moved it: epochs handle the common case — thousands of pages, retired in one tick — and a tiny refcount covers the narrow case epochs structurally can't see, the raw pointer that escapes its epoch. The 2N tax is gone from the hot path; what remains is a counter that almost never moves.

🧰 Two details worth stealing

Cache-line-pad the per-thread slots. The registry's whole reason to exist is that threads pin and unpin without fighting each other. Pack two threads' epoch fields into one cache line and you've reintroduced exactly the false-sharing the design set out to kill. Each slot is its own cache line:

// EpochThreadRegistry — one cache line per thread, no false sharing on pin/unpin
[StructLayout(LayoutKind.Explicit, Size = 64)]
internal struct PaddedEpochSlot
{
    [FieldOffset(0)]  public long PinnedEpoch;  // hot: written every enter/exit
    [FieldOffset(8)]  public int  Depth;        // hot: nesting depth
    [FieldOffset(12)] public int  SlotState;    // warm: CAS on claim/free
    // bytes 16–63: padding to fill the line
}

A pinned epoch is a liability if its thread dies. A thread that pins an epoch and then crashes or exits without unpinning would hold MinActiveEpoch down forever — freezing eviction across the whole cache. Two safeguards catch it: each slot is owned by a CriticalFinalizerObject that releases it when the thread is collected, and the MinActiveEpoch scan does a Thread.IsAlive liveness check, reclaiming any slot whose owner has died. The grace period is robust to threads that never come back.

🎯 The takeaway

Reference counting is the reflex answer to "don't free this while someone's using it," and for a lot of code it's the right one. But it answers a harder question than most callers ask. When you don't need who or how many — only is it safe yet — epoch-based reclamation turns O(N) contended bookkeeping into O(1): publish a number on the way in, tick a number on the way out, and let a grace period retire everything at once. The cost is that protection is coarse, so it fits workloads whose units of work are bounded — which, for a database built for game ticks and simulation frames, they are by construction.

That's the pattern worth keeping even if you never touch Typhon: before you reach for a counter, check whether you actually need the count, or just the guarantee.

⏭️ What's next

Post #7: MVCC at Microsecond Scale: Snapshot Isolation Without Cloning Rows. Those epoch-stamped pages are where revision chains live — every update appends a new version instead of overwriting, readers see a frozen snapshot, and old revisions get retired by the same kind of grace-period reasoning you just read. Next post pulls that thread.

Follow the GitHub repo for source and benchmarks, or subscribe via RSS.

A Database You Can See

Loïc Baumann — Mon, 08 Jun 2026 14:45:25 +0000

💡Typhon is an embedded, persistent, ACID database engine written in .NET that speaks the native language of game servers and real-time simulations: entities, components, and systems.

It delivers full transactional safety with MVCC snapshot isolation at sub-microsecond latency, powered by cache-line-aware storage, zero-copy access, and configurable durability.

Series: The Typhon Workbench — the tools that make the engine usable

A Database You Can See (this post)

You Can't Optimize What You Can't See (coming soon)

Querying by Hand (coming soon)

A lighter, hands-on companion to the engine deep-dive series, A Database That Thinks Like a Game Engine.

GitHub repo • 📬 Subscribe via RSS

I spent long time making Typhon fast. Sub-microsecond commits, MVCC snapshot isolation, cache-line-aware storage — the kind of numbers that make a systems programmer lean in. Then I opened a .typhon file to debug something, and realized I was staring at a black box. I had built an engine I couldn't see into.

That's the quiet trap of infrastructure software: the better the engine, the more invisible it is. A database that does its job disappears — right up until the moment you need to know what your schema actually looks like in memory, which systems touch a component, or whether a query does what you think. At that moment, raw speed is worth nothing without a way to look inside.

So this post starts a new, lighter track in the series — about the Typhon Workbench, the tool that makes the engine usable. The thesis is simple and, I think, under-appreciated:

🎯 Great technology is not enough. You need tools that let people make the most of it.

So, concretely: the Workbench is the tool you keep open to understand a Typhon system — its data, its schema, and its behavior — whether that system is a file on disk, a captured trace, or a live engine you're attached to. It's built for both developers and ops. Developers use it to understand structure and chase performance: how an archetype is laid out, what's actually stored on an entity, where the time goes.

Ops and reliability engineers use it to watch a live system — tick rate, jitter, overload, queue depth — and to freeze the feed or capture a window when something spikes. Either way, it answers what code alone can't: What does my schema really look like? What's in this archetype right now? Which systems touch this component? Why did that tick stall? Is the engine healthy? — the things you'd otherwise chase with Console.WriteLine, log scraping, and a lot of guessing. This first post stays on the data-and-schema side; later in the track we reach the profiling and live views.

A quick note on what it's built from, for the curious: the Workbench is a small full-stack app that runs entirely on your machine. The backend is ASP.NET Core (Kestrel) speaking to the engine; the frontend is React 19 + TypeScript built with Vite, styled with Tailwind CSS and shadcn/ui (Radix primitives), using dockview for the draggable panel layout, Zustand and TanStack Query for state, and cmdk behind the command palette. Nothing leaves localhost.

See it first

Before the words, here's the two-minute tour:

▶ Watch "Typhon Workbench intro" on YouTube — if the embed doesn't load in your viewer

DataGrip meets a flight recorder

The Workbench is a local developer tool. You point it at a Typhon database — a .typhon file on disk — and it opens a window into everything inside: the schema, the data, and the way both sit in memory and on disk. It can also attach to a live engine or replay a captured trace, but this post is about the simplest, most common case: you have a database file, and you want to understand it.

If you've used JetBrains DataGrip, DBeaver, or MongoDB Compass, the shape is familiar — a navigator down one side, an object inspector, a data grid, drill-downs. That's deliberate. I didn't want to invent a new mental model for "exploring a database"; the last thirty years of database tooling already converged on one that works, and the Workbench borrows it wholesale. What it adds is the part that's specific to Typhon: it speaks entities, archetypes, and components natively, and it can show you things a row-store tool never could — cache-line layouts, on-disk fragmentation, the cost of a query before you run it. (The other half of the name — the flight recorder, for profiling a running engine — is a story for a later post in this track. Here we stay with the database.)

There's no install ceremony — open it, point it at a file, and it's out of your way in seconds.

From a file to a model you can walk

Open a .typhon file and you don't get a hex dump or a list of opaque page numbers. You get a model you can walk, top to bottom.

It starts with the Schema Explorer — a tree of your archetypes. As the engine series describes, Typhon stores data the way a game engine does: an archetype is a set of entities that share the same component composition, which makes it the rough equivalent of a table. The Schema Explorer lists them all, with the numbers that matter at a glance — how many entities each holds, which components it carries, how full its storage is. It's fuzzy-searchable, so on a schema with a hundred archetypes you type three letters and you're there.

From an archetype you drill into a Component, and this is where it stops looking like a generic table browser and starts looking like something built for this engine. A component isn't just a column; it has tabs for its fields, the archetypes that use it, the systems that read and write it, its storage mode. (One of those tabs — the memory layout — gets a whole post to itself next time. It earns it.)

Three things from the video are worth calling out, because they're the difference between a tool you tolerate and one you live in:

Density is a setting. I stare at this thing all day, so it ships compact by default — more rows, less chrome — but you can loosen it when you'd rather have room to breathe.
Dark and light both exist and both work. Not a switch bolted on at the end; the whole UI is built on theme variables, so nothing breaks when you flip it.
The command palette is the spine. One shortcut gives you a single search box that reaches everything — every view, and every object in your database. Type a component's name and jump straight to it; prefix your search to scope it (one prefix runs actions, another finds an object in the current session, another jumps to a moment in a trace). Anything you can reach with the mouse, you can reach from the keyboard. That isn't a power-user garnish — it's how discoverability works. Someone who doesn't know where a feature lives can find it by typing what they want.

One click, every view

Here's the part that took the most work and is the easiest to miss: in the Workbench, selection is global.

Select a component — anywhere, in any panel — and the whole tool reorients around it. The inspector shows its details. The archetypes that use it light up. The systems that read it and the systems that write it appear together, so you can see the blast radius of a change before you make it: if I touch this field, here's everything that cares. You made one gesture; several panels answered.

That sounds obvious until you remember how it usually goes. In most toolchains every view is an island. You find an ID in one window, copy it, paste it into another, lose your place, open a third. The friction is so normal you stop noticing it — you just accept that "investigating" means juggling. The Workbench's bet is that you shouldn't have to: one selection, shared across every panel, reversible with a back button that always takes you home.

The honest part: none of the individual panels were the hard problem. Most of them existed already. The hard problem was the wiring — a single shared notion of "what is selected" that every panel both listens to and can drive. That's the unglamorous work that turns a folder full of capable views into something that feels like one product. It's invisible when it works, which is exactly why it's worth pointing at.

Real data, decoded

Schema is half the story. The other half is what's actually in there.

The Data Browser pages through the real entities in an archetype and shows their component values decoded — not raw bytes, not a blob you have to interpret, but Position { X = 124.5, Y = 88.1 }, Health = 98, the actual values your systems are reading. Pick the columns you care about, page through, click a single entity to inspect it on its own. And it's strictly read-only: looking never changes what's there, so you can explore a production capture without a second thought.

It closes the loop the rest of the tool sets up. You walked the schema from archetype to component; now you see the data sitting in that shape. From a row you can select a component value and — because selection is global — bounce straight back to the schema side to ask "wait, how is this field actually laid out?" The investigation flows in both directions, which is the whole point.

The lesson: tools need design too

Let me end on the thing this whole post is really about.

Typhon's engine solved a genuinely hard problem: ACID transactions at microsecond latency, on a data model borrowed from game engines, with none of the usual compromises. That took two years and most of my stubbornness. But an engine is a capability, not an experience. The moment a real developer sits down — to debug a schema, to understand why something is slow, to check what's actually in the database — that capability is only as good as their ability to reach it.

The Workbench is the other half of that work, and it needed its own kind of design discipline — none of it about raw performance:

One action, not three. Any move you'd want to make is a single gesture from where you already are.
No dead buttons. A control that renders is a control that works. Nothing that looks clickable does nothing — broken affordances erode trust faster than missing features ever do.
Selection is global and reversible. One click drives everything; the back button always brings you home.
Speed without orientation is just a faster way to get lost. Fast and oriented, or it doesn't count.

That's the under-appreciated half of building good technology: the tools aren't a cherry on top, they're the path the value travels to reach a human being. You can have the fastest engine in the world, and if nobody can see inside it, you've built a very elegant black box. I'd rather build one you can see.

What's next

Next in the Workbench track: You Can't Optimize What You Can't See — where the abstract gets physical. The component layout grid shows you cache lines, field padding, and alignment as something you can actually look at; the File Map draws your entire database on disk, fragmentation and all. Meanwhile the engine track continues its deep dives.

Follow the GitHub repo for source and benchmarks, or subscribe via RSS.

Three Durability Modes, One WAL: Configurable Guarantees for Different Workloads

Loïc Baumann — Wed, 20 May 2026 11:21:06 +0000

💡Typhon is an embedded, persistent, ACID database engine written in .NET that speaks the native language of game servers and real-time simulations: entities, components, and systems.

It delivers full transactional safety with MVCC snapshot isolation at sub-microsecond latency, powered by cache-line-aware storage, zero-copy access, and configurable durability.

Series: A Database That Thinks Like a Game Engine

Why I'm Building a Database Engine in C#

What Game Engines Know About Data That Databases Forgot

Microsecond Latency in a Managed Language

Deadlock-Free by Construction

Three Durability Modes, One WAL (this post)

MVCC at Microsecond Scale (coming soon)

GitHub repo • 📬 Subscribe via RSS

Most databases pick one durability strategy at boot time. Typhon picks one per commit — and the surprising part isn't the user-facing API, it's that all three modes share the same WAL (Write-Ahead Log — every commit appends a record here before being durable) writer thread, the same ring buffer, the same I/O path. The only thing that differs is whether the producer waits.

Ten thousand NPC position updates per simulation tick at ~1-2µs each, all Deferred. One legendary item drop on the same transaction code path, escalated to Immediate, paying ~15-85µs for a guaranteed FUA (Force Unit Access — don't ack the write until it's on stable media) write to disk. Same engine, same WAL, one extra argument at Commit(). This post is about why that's possible and what it cost to keep it that way.

The other classical knob

Post #4 covered Typhon's first big architectural bet — eliminating deadlocks at the design level instead of detecting them at runtime. This one is about the other classical database knob: durability. And like deadlocks, the interesting decision is upstream of the implementation.

Three workloads sit on the same engine in a real game server:

Simulation tick: physics, AI, position updates. Hundreds to thousands of writes per frame. Losing the last tick on crash is fine; the simulation will recompute it.
Player actions: combat events, item pickups, dialogue state. Sub-5ms data loss window is acceptable. Throughput matters more than per-commit durability.
Money and rare events: currency transfers, legendary drops, account creation. Zero tolerance for loss. Players will dispute every missing transaction.

A single global durability setting forces all three to the most conservative option — and ~15-85µs per FUA write turns a 60Hz tick budget (16ms) into a fight you've already lost.

The three modes

The decision lives on the Unit of Work (UoW) at creation time, with a per-transaction override for escalation only. A UoW sits one level above a transaction: it groups one or more transactions and owns the durability contract they share. Transactions still commit atomic state changes; the UoW decides when — and whether — those commits reach disk. The user-facing enum is exactly what it looks like:

public enum DurabilityMode : byte
{
    /// <summary>WAL records buffered. Durable only after explicit Flush()/FlushAsync().
    /// Commit latency: ~1-2µs. Data-at-risk: until Flush().</summary>
    Deferred = 0,

    /// <summary>WAL writer auto-flushes every N ms (default 5ms).
    /// Commit latency: ~1-2µs. Data-at-risk: ≤ GroupCommitInterval.</summary>
    GroupCommit = 1,

    /// <summary>FUA on every tx.Commit(). Blocks until WAL record is on stable media.
    /// Commit latency: ~15-85µs. Data-at-risk: zero.</summary>
    Immediate = 2,
}

public enum DurabilityOverride : byte
{
    Default   = 0,  // Use the UoW's DurabilityMode
    Immediate = 1,  // Force FUA for this specific commit (escalation only)
}

The override can only escalate. A Deferred UoW can promote one transaction to Immediate; an Immediate UoW cannot weaken anything. This is a deliberate constraint, not an oversight — it makes data-loss bugs impossible by API shape. You can never accidentally make a transaction less durable than the UoW's contract.

Mode	Commit latency	Data-at-risk window	Use case
`Deferred`	~1-2µs	Until explicit `Flush()`	Game ticks, batch imports, simulation steps
`GroupCommit`	~1-2µs amortized	≤ 5ms (configurable)	General server load, request handlers
`Immediate`	~15-85µs	Zero	Trades, account writes, legendary drops

One writer thread, three signaling patterns

Here's the part that surprised me when I came back to the design six months in: I did not need three I/O paths. Or three threads. Or three buffers. The shared infrastructure looks like this:

The same picture broken into phases:

#	Producer thread (`tx.Commit()`)	What this means for you	WAL Writer thread (single, dedicated)	What this means for you
1	`TryClaim()` — CAS (Compare-And-Swap) slot allocation	Your commit atomically reserves a slot in the WAL ring buffer. No lock contention with other transactions claiming slots in parallel.	(idle, or finishing a previous drain)	The writer thread runs independently. Your producer never waits on it to claim a slot.
2	`Publish()` — release-store the frame header	The record is now visible to the writer. Your commit has an LSN (Log Sequence Number) — its position in the durability timeline.	`TryDrain()` — contiguous batch of published frames	The writer harvests every published slot in one pass. This is the structural reason `GroupCommit` is amortized: N producers, one drain, one FUA cost.
3	Mode-specific: return now, or `WaitForDurable(lsn)`	Deferred / GroupCommit: `Commit()` returns in ~1-2µs and durability lands asynchronously. Immediate: `Commit()` returns only once your LSN is on disk (~15-85µs).	`WriteAligned()` → FUA write → `Interlocked.Exchange(DurableLsn)` → `_durabilityEvent.Set()`	One physical FUA write per batch (~15-85µs, paid once). `DurableLsn` advances; any Immediate waiter whose LSN ≤ `DurableLsn` wakes and returns from `tx.Commit()`.

What changes between the modes is only the producer side:

Deferred — Publish and return. No signal, no wait. The writer may be asleep; it will wake on the next group-commit timer or explicit Flush().
GroupCommit — Publish and return. The writer is already in a WaitForData(GroupCommitIntervalMs) loop; the next tick of that timer (≤5ms) drains the batch.
Immediate — Publish, signal the writer, then WaitForDurable(lsn) until DurableLsn advances past the producer's LSN.

That last one is where the elegance lives. It's not a separate code path — it's the same path, with one extra fast-path check:

public void WaitForDurable(long lsn, ref WaitContext ctx)
{
    // Fast path: already durable, returns inline.
    if (Interlocked.Read(ref _durableLsn) >= lsn)
    {
        return;
    }
    WaitForDurableSlow(lsn, ref ctx);
}

If the WAL writer has already drained past your LSN by the time you call this — say, because someone else's Immediate commit just batched yours along with it — you pay one atomic read and a return. No event wait, no syscall, no context switch. Immediate mode is GroupCommit's batching benefit, available to the one transaction that needs it now.

That's the teaching moment I want this post to leave you with: per-transaction durability is not three implementations. It's one implementation with three producer-side policies, and the FUA cost is a property of the I/O path, not the API surface.

Per-UoW, not per-engine — why

The API-shape decision is recorded in its own ADR (Architecture Decision Record). I considered four alternatives before landing on per-UoW:

Alternative	Why I rejected it
Per-database (boot-time)	Too coarse. Game ticks and trades on the same DB need different modes within the same process.
Per-transaction	Can't batch — `GroupCommit` is inherently multi-transaction. The UoW is the natural batching boundary.
Two modes (Sync / Async)	Misses `GroupCommit`'s sweet spot. The whole point is amortized FUA, which a binary doesn't capture.
Caller-managed flush only	Error-prone. Developers forget to flush. `GroupCommit` automates the common case correctly.

The honest version: I tried "per-database" first because it was easiest to wire up, and immediately hit the simulation-vs-trade problem on the first benchmark. Two production game-server workloads on the same engine, one wanting ~1µs commits and one wanting zero data loss. The mode has to follow the workload, not the storage.

Numbers that matter

The latency table above is the headline. The throughput table is where it gets interesting:

Mode	Single-thread durable tx/s	Multi-thread durable tx/s
`Deferred`	N/A (batch-durable)	N/A
`GroupCommit` (5ms interval)	~200K+ amortized	Millions (shared flush)
`Immediate`	~12K-65K	~12K-65K (FUA-limited)

Single-thread Immediate is capped by NVMe FUA round-trip — there's no software trick to escape that. But multi-thread Immediate does not scale linearly past one thread, because every commit is racing the same writer through the same I/O. GroupCommit, on the other hand, scales nearly with thread count because the FUA cost is paid once per drain cycle no matter how many producers contributed to the batch.

That's not a flaw in Immediate. It's the physics of the storage device. The point of having three modes is that you only pay that cost where you actually need it.

What I got wrong

The first group-commit timer was 1ms. Under low write load the WAL was doing constant small FUA writes — worst-case for SSD wear and tail latency. Tuning to 5ms with a "wake on N records OR T milliseconds" trigger fixed it: the writer sleeps on WaitForData(intervalMs) and gets pulled out early when a producer signals (Immediate commits, explicit Flush(), or back-pressure). Idle periods cost nothing; busy periods batch naturally.

The first override design allowed downgrade. tx.Commit(DurabilityOverride.Deferred) from an Immediate UoW. The use case was "this single read-mostly transaction doesn't really need FUA." The use case was wrong: the UoW's contract is the durability floor, not the default. Downgrading a single commit means the application has accidentally created a hole in a contract it thinks it has. Now overrides can only escalate, and the type system enforces it.

Deferred mode is a contract, not a latency number. Early users assumed Commit() always meant "on disk." It doesn't. Deferred mode says: your data is not durable until you call Flush() or close cleanly. For game servers that's fine; their tick loop already has clear boundaries. But the documentation now leads with the contract, not the µs number. The latency is a consequence; the contract is what you signed up for.

What's next

Post #6 in the series: Building a Page Cache That Doesn't Count: Epoch-Based Memory Management. The durability story above assumes the commit path is fast, but that's only half the story — the read path has to be just as cheap, and the trick there is replacing per-page reference counting with epoch-based protection: two atomic operations per transaction instead of two per page. The mechanism is elegant enough that it deserves its own post.

Follow the GitHub repo for source and benchmarks, or subscribe via RSS.

Deadlock-Free by Construction: How Typhon Eliminates Deadlocks Instead of Detecting Them

Loïc Baumann — Mon, 27 Apr 2026 17:48:24 +0000

💡Typhon is an embedded, persistent, ACID database engine written in .NET that speaks the native language of game servers and real-time simulations: entities, components, and systems.

It delivers full transactional safety with MVCC snapshot isolation at sub-microsecond latency, powered by cache-line-aware storage, zero-copy access, and configurable durability.

Series: A Database That Thinks Like a Game Engine

Why I'm Building a Database Engine in C#

What Game Engines Know About Data That Databases Forgot

Microsecond Latency in a Managed Language

Deadlock-Free by Construction (this post)

MVCC at Microsecond Scale (coming soon)

GitHub repo • 📬 Subscribe via RSS

Deadlocks are usually treated as a runtime problem. We treat them as a design bug.

That sounds like a slogan. It isn't. It's the actual reasoning behind three architectural decisions that, taken together, make a lock-dependency cycle impossible in Typhon — not unlikely, not rare, impossible. The engine ships without a deadlock detector. From the project's own concurrency overview:

Deadlock detection is explicitly not implemented — it would add overhead for a scenario that cannot occur in the current architecture.

This post is the how: how three structural decisions remove three classes of edges from the lock-dependency graph, and how that elimination cascades into "no cycle is possible." But it's also the why: why the constraint was set at project inception, before any code existed to deadlock, and what it cost.

The upfront bet

I didn't compare deadlock detection schemes before starting Typhon. I'd seen them in production at previous engines, and the pattern was always the same: a separate background scanner, a wait-for graph, victim selection heuristics, transaction abort and retry. A lot of code. A lot of edge cases. None of it bulletproof for the user, who still sees occasional one-second pauses or unexplained transaction failures under load.

So I made an upfront call, recorded as ADR-003, the project's first concurrency decision, dated 2024-01 (project inception):

Optimistic locking: No locks during execution; conflict detection only at commit.

(ADRs — Architecture Decision Records — are short documents capturing one design choice with its context and rationale. They're a paper trail for why a thing was built a particular way, not just what it does. Typhon has 49 of them so far. They live in the project's internal documentation, not in the public repo.)

That's the bet. No locks across data, whatever the architectural cost. Not because I had proof prevention would be faster — I didn't run those benchmarks — but because the implementation cost of detection is real, the result is never bulletproof, and trading an architectural cost up front for never paying a runtime cost later is the trade I wanted.

The three "pillars" that follow aren't a survey of alternatives I considered. They're what the architecture had to become once the constraint was set. MVCC was the obvious starting point. Optimistic Lock Coupling for indexes followed because traditional B+Tree latch coupling violated the constraint at the index level. The "no cross-table latching" rule emerged because anything else reintroduced the cycles I was trying to eliminate.

It's constraint-driven design, not survey-driven. And it's why this post claims a property — deadlock-free by construction — instead of a benchmark.

What a deadlock actually is

Briefly, because the rest of the post needs the picture.

Two transactions, T1 and T2. T1 holds a lock on row A and asks for a lock on row B. T2 holds B and asks for A. Neither can proceed. Each is waiting for the other; the wait will never end. That's a cycle in the lock-dependency graph — the directed graph whose nodes are transactions and whose edges are "is waiting for." A deadlock is a cycle in that graph. Detection-based databases scan for cycles and break them by aborting one transaction. Prevention-based databases make cycles impossible to form.

The three sections that follow each remove one class of edges from that graph. With every class removed, no cycle is possible.

Pillar 1: MVCC eliminates inter-transaction data locks

The textbook deadlock — T1 locks row A, T2 locks row B, both want the other — requires row-level locking between transactions. Typhon doesn't do that.

Reads are snapshot-consistent: every transaction is frozen at the global tick value when it began. A reader sees a stable view of the database for its entire lifetime. It never asks for a lock, because there's nothing to lock against — the snapshot is already immutable.

Writes don't lock existing rows either. They create new revisions, with the previous revision left intact for any transaction whose snapshot still references it. Two writers updating the same component don't fight over a lock; they each append a new revision to the chain. Conflict detection happens at commit time, as a single CAS operation: when the writer tries to install its new revision as the current one, the engine checks that the version it built on is still current. If not, the writer aborts and retries.

This removes the entire edge class of "data locks held across transactions." There are no row locks, no read locks, no write locks on data. The wait-for graph at the transaction level has no edges to form a cycle from.

The cost isn't free. Two writers updating the same component will conflict at commit, and one of them will retry. For game-server workloads where most components are written by exactly one system, conflicts are rare. For general OLTP workloads with high write contention, the cost would shift the trade — fewer deadlocks, more aborts. Different curve.

Pillar 2: Optimistic Lock Coupling for index structures

Even without row locks, an index structure (B+Tree, R-Tree) is shared mutable state. Traditional databases serialize access through latch coupling: a reader holds a latch on the parent node while acquiring one on the child, releases the parent, advances. It's a chain of overlapping latches walking down the tree.

That pattern can deadlock. Reader R has the parent latched and wants the child; concurrent writer W has the child latched and walks back up to fix the parent. Two threads, two index latches, mutual wait.

Typhon uses Optimistic Lock Coupling (Leis et al., 2019) instead. Readers don't latch at all. Each B+Tree node carries a 32-bit version counter. The reader reads the version, traverses, then re-reads the version at the end — if it changed, the traversal data may have been mutated mid-flight, so the reader restarts.

// From Typhon.Engine/Data/Index/OlcLatch.cs
public int ReadVersion()
{
    int v = _version;
    return (v & 0b11) == 0 ? v : 0;  // locked (bit 0) or obsolete (bit 1) -> restart
}

public bool TryWriteLock()
{
    int v = _version;
    if ((v & 0b1) != 0) return false;
    return Interlocked.CompareExchange(ref _version, v | 0b1, v) == v;
}

public void WriteUnlock()
{
    int v = _version;
    _version = ((v >> 2) + 1) << 2 | (v & 0b10);  // version++, keep obsolete, clear lock
}

Bit 0 is the write-lock flag; bits 2–31 are a monotonic version counter. ReadVersion returns 0 if the node is locked or obsolete — the caller treats that as "restart." TryWriteLock is a single CAS. WriteUnlock increments the version atomically with releasing the lock.

Writers latch only the modified nodes, and they acquire from root to leaf, in strict order. No reader ever blocks a writer. No writer ever holds a parent latch while waiting on a child. The same pattern is reused by the spatial R-Tree — same OlcLatch, same protocol — so this single mechanism covers both index families.

This removes the edge class of "index-level latch cycles."

Pillar 3: No cross-table latch holding

Two edge classes are gone. The third is the most boring and the most important: at any given moment, a thread never holds a latch in more than one table.

Each ComponentTable in Typhon has independent indexes, independent revision chains, independent page allocations. A transaction's commit path processes one table at a time. When the commit moves from table A to table B, all of A's latches are released first.

The only resource that would be shared across tables is the page cache. Latches there could form cycles across the entire engine. So the page cache doesn't use latches. That refactor is recorded as ADR-033, dated 2026-02-12:

Replace per-page reference counting with epoch-based protection. Each transaction enters an epoch scope that pins the current global epoch; pages accessed within the scope are stamped with that epoch; eviction defers any page whose epoch is still active.

The previous approach was reference counting: every page access incremented a counter, every release decremented it. A transaction touching 100 pages paid for 200 atomic operations — and atomics aren't free, each one stalls the CPU pipeline waiting for cache-line coherence. Epochs collapse that into two operations regardless of how many pages the transaction touches: one to enter the scope, one to exit.

But the deadlock-freedom payoff isn't the cost reduction. It's that the page cache never holds a lock anyone else could wait on. No latch, no waiter queue, no edge in the lock-dependency graph at all.

This removes the last edge class — cross-structure cycles. With all three classes gone, there is no graph in which a cycle can form.

This pillar is the one I worry about most, and the one most likely to break in the future. It's enforced by convention, not by the type system. Future features — cross-table indexes, parallel query execution holding read latches across multiple tables, foreign-key constraints — would each require extending the lock-hierarchy discipline. The concurrency overview explicitly lists those scenarios as known risks. I'll have to introduce explicit lock ordering when I get there.

What the bet costs

Prevention isn't free; it just shifts the cost.

What's eliminated	What remains
Deadlocks (cycles in the lock graph)	Aborts at commit — local retry
Detection runtime overhead	OLC restarts under index contention
Wait-for-graph data structures	Livelock under heavy contention (different problem)

A writer that loses the commit-time CAS doesn't trigger a global abort — it retries from where it was, against a refreshed baseline. An OLC reader that sees a version change doesn't block a writer — it restarts the traversal. These are local costs. A Postgres deadlock victim aborts the entire transaction; a Typhon OLC restart is one tree traversal.

Livelock — repeated retries that never converge — is a different beast. It can't deadlock, but it can starve. Typhon's AdaptiveWaiter handles this with a spin-then-yield progression: 65,536 tight spin iterations first (most contention resolves there), then exponentially halving spin counts interleaved with Thread.Sleep(100µs). The 100µs sleep is below the OS scheduler quantum, so wake latency stays sub-millisecond. It bounds livelock probability without trading away the latency targets.

So: deadlocks gone, aborts and restarts kept, livelock bounded by a spin policy.

What others do

I didn't survey these in depth before committing to prevention — the upfront "no locks" constraint was made on principle. But for the reader's context, here's the landscape Typhon sidesteps.

System	Strategy	Cost model
PostgreSQL	Wait-for graph, triggered after `deadlock_timeout` (1s default)	Detection deferred to ≥1s lock wait; cycle scan is expensive but rare
MySQL InnoDB	Wait-for graph + victim selection (smallest tx by row modifications wins)	Detection can be disabled on high-concurrency systems in favor of `innodb_lock_wait_timeout`
CockroachDB	Per-node in-memory lock tables + Raft-replicated write intents	Detection is near-instantaneous; cost shifted to lock-table maintenance
Typhon	Prevention by structure (three pillars above)	No detection runtime cost; cost shifted to OLC restarts and commit-time aborts

These are all sound engineering choices for their workloads. Postgres' deferred detection is rare-event optimization. InnoDB's "smaller transaction wins" is a pragmatic heuristic for the OLTP shapes it's tuned for. CockroachDB's instantaneous detection genuinely solves the latency problem detection has elsewhere. None of these are wrong. They're answering a different question: given that we accept locks, how do we manage their cycles?

Typhon answers a different question: given that we don't accept locks, what does the rest of the architecture have to look like? That's why the comparison isn't "Typhon is faster" — it's "Typhon paid the cost in a different layer." Each row above describes where the cost lives, not who's faster.

A footnote: TigerBeetle reaches the same end via a different upfront constraint — single-writer serializable execution. No concurrent transactions, no deadlocks. Different category, same conclusion: detection is the wrong layer to solve this.

What I'd flag for a reviewer

Three honest acknowledgments.

Pillar 3 is enforced by convention, not by the type system. The compiler won't catch a future PR that holds latches across two ComponentTables. The discipline lives in code review and architectural awareness, not in mechanically-checked invariants. To compensate, I've set up a list of explicit design rules that Claude Code enforces during design, development, and code review. Pillar 3's "no cross-table latching" invariant is on that list; any code that would violate it gets flagged before it reaches the diff.

OLC restart cost is bounded but not zero. Under heavy write contention on a hot B+Tree leaf, optimistic readers can restart a few times before getting a clean version. The restart is one traversal, not a transaction abort, but it's not free either.

The "deadlock-free" claim assumes the current feature set. Cross-table indexes, parallel queries holding read latches across tables, and foreign-key constraints are all listed as future scenarios that would require extending the discipline. The structural argument holds for what ships today; future features will need to maintain it consciously.

What's next

The next post drills into Pillar 1 — how Typhon's MVCC works without cloning rows. The big trick is per-component revision chains instead of per-row tuple versioning: an entity with eight components that updates one creates a single new revision, not eight. The visibility check is a single comparison against the transaction's snapshot tick. And the EnabledBits exception dictionary pattern — zero-overhead fast path, dictionary slow path — is the prettiest piece of code in the engine.

Microsecond Latency in a Managed Language: The Performance Philosophy Behind Typhon

Loïc Baumann — Sun, 12 Apr 2026 20:58:24 +0000

💡Typhon is an embedded, persistent, ACID database engine written in .NET that speaks the native language of game servers and real-time simulations: entities, components, and systems.

It delivers full transactional safety with MVCC snapshot isolation at sub-microsecond latency, powered by cache-line-aware storage, zero-copy access, and configurable durability.

Series: A Database That Thinks Like a Game Engine

Why I'm Building a Database Engine in C#

What Game Engines Know About Data That Databases Forgot

Microsecond Latency in a Managed Language (this post)

Deadlock-Free by Construction (coming soon)

GitHub repo • 📬 Subscribe via RSS

The first two posts in this series covered the why and the what. Why C# for a database engine. What happens when you combine ECS storage with database guarantees.

This post is the how. Specifically: the five design principles that guide every performance decision in Typhon. Not a bag of tricks — a philosophy. Individual optimizations come and go as the engine evolves, but these principles are stable. They're what let a managed language deliver sub-microsecond transaction latency.

When your tick budget is 16 milliseconds and you have 100,000 entities to process, every nanosecond of per-entity cost matters. And most of that cost comes from decisions made at design time, not runtime.

Principle 1: Control Memory Layout

Performance starts at the struct definition, not the algorithm. If your data layout causes cache misses, no algorithm can save you.

The most dramatic example: Typhon recently moved from per-entity hash-table lookups to cluster-based Structure of Arrays (SoA) storage. Same data, same queries, different memory layout. Measured on a Ryzen 9 7950X:

Path	ns / entity	vs baseline
Standard EntityAccessor	139 ns	1.0x
ArchetypeAccessor (cached)	94 ns	1.5x
Cluster iteration	2.5 ns	55x

That's a 55x improvement from changing memory layout alone. The reason: clusters pack N entities (8 to 64, auto-computed per archetype) in contiguous SoA memory. All positions together, all health values together. Every cache line the CPU loads is 100% useful data. For 100K entities, the working set dropped from scattered L3/DRAM access to ~2.5 MB that fits entirely in L2 cache — and L2 is 3x faster than L3 on Zen 4.

The cluster size isn't a magic constant. An auto-tuning algorithm evaluates every N from 8 to 64 and picks the one that maximizes entities per 8 KB page for a given archetype's component schema. Non-power-of-2 sizes often pack better: N=14 can yield 28 entities per page vs N=16 yielding only 16. The capacity is derived from the data, not from convention.

False sharing is the other side of layout control. When multiple threads write to adjacent fields, the CPU bounces the shared cache line between cores — a 40-60 cycle penalty per bounce. Typhon wraps mutable per-thread state in 64-byte padded structs. The WAL commit buffer goes further: explicit padding fields isolating the producer's _tailPosition and the consumer's _drainPosition onto separate cache lines. Seven unused long fields between them, suppressed with #pragma warning, because the correct layout matters more than the linter's opinion.

The same hardware awareness drives B+Tree node sizing:

[StructLayout(LayoutKind.Sequential, Pack = 4)]
unsafe public struct Index32Chunk
{
    // 256 bytes — fills four cache lines. Adjacent Line Prefetcher (ALP) on
    // Zen 4+/recent Intel automatically fetches paired 64-byte lines within
    // 128-byte regions, so two ALP triggers cover the full node.

    public const int Capacity = 29;

    public int Control;
    public int OlcVersion;       // bit 0 = locked, bit 1 = obsolete, bits 2-31 = version
    public int PrevChunk;
    public int NextChunk;
    public int LeftValue;
    public int HighKey;          // B-link upper bound
    public fixed int Values[Capacity];  // 29 × 4 = 116 bytes
    public fixed int Keys[Capacity];    // 29 × 4 = 116 bytes
}

This struct is exactly 256 bytes because of the CPU's prefetcher. The Adjacent Line Prefetcher on modern x86 fetches paired 64-byte lines within 128-byte aligned regions — so two ALP triggers cover the full node. A 256-byte node costs effectively the same as a 128-byte node in terms of memory access, but holds nearly twice the keys.

The capacity of 29 keys isn't a round number because it isn't derived from the algorithm. It's derived from the hardware: 256 bytes of budget minus 24 bytes of header, divided across Keys and Values arrays. Typhon has three B+Tree variants — 16-bit, 32-bit, and 64-bit keys — and all three hit exactly 256 bytes with different capacities (38, 29, and 19 keys respectively). Post #1 mentioned 128-byte nodes. We've since moved to 256 bytes after measuring ALP behavior on Zen 4 — capacity went up, lookup latency stayed flat.

Principle 2: Eliminate Allocations on Hot Paths

In .NET, every allocation is a future GC event. On hot paths, the cost isn't the allocation itself (~5 ns) — it's the Gen0/Gen1 collection later that pauses unrelated threads. The discipline is simple: allocate nothing in steady state.

ref struct is the primary weapon. A ref struct lives on the stack, dies when the scope ends, and the GC never knows it existed. Post #1 showed EntityRef (96 bytes, inline component cache). But ref structs are a systematic discipline in Typhon, not a one-off optimization:

OlcLatch: wraps a single ref int — the B+Tree node's version field. The entire optimistic lock coupling protocol (read version, validate, try-write-lock) in a struct that's basically a typed pointer. Allocated millions of times per second during tree traversal, at zero GC cost.
EpochGuard: RAII scope for epoch-based page protection. Enter and exit in 3.3 ns. Because it's a ref struct, it can't be boxed, captured in a closure, or passed to async code — exactly the constraints you want for a scope guard.
WalClaim: a Write-Ahead Log buffer claim containing a Span<byte> that points directly into native WAL memory. Can't escape to the heap by construction — the Span field makes it a ref struct automatically.
PointInTimeAccessor: a reusable snapshot attached to parallel workers. One per worker, stored in a flat array indexed by worker ID. Zero per-entity dictionary overhead — no Dictionary<EntityId, T> on the hot path.

For short-lived buffers, stackalloc with a threshold pattern: stack-allocate when the array is small (under 64 elements), fall back to the heap otherwise. Most arrays stay small, so they never touch the allocator.

For larger long-lived buffers, the Pinned Object Heap: GC.AllocateArray<byte>(capacity, pinned: true). Pre-zeroed by the OS, never compacted by the GC, stable pointer for direct access. Typhon's HashMap uses this for its entire entry array.

For medium reusable buffers, ArrayPool<T>.Shared. FPI compression rents 9 KB buffers, returns them in a finally block. Query execution rents stream arrays sized for the common case (8 slots), doubles if needed.

Four strategies — ref struct for scoped access, stackalloc for small temporaries, POH for large long-lived buffers, ArrayPool for medium reusable buffers. The result: zero hot-path allocations in steady state.

Principle 3: Reduce Memory Indirections

Every pointer chase is a potential cache miss. An L3 hit costs ~100 cycles, a DRAM miss costs ~200+. The goal: minimize the number of hops from "I want this data" to "here's the data."

Post #1 showed the flagship example — the SIMD chunk accessor with its 3-tier lookup (MRU check, Vector256 search, clock-hand eviction). Each tier reduces indirection compared to the next.

Epoch-based page protection eliminates another class of indirection. The traditional approach: atomic increment on page access, atomic decrement on release. For N page accesses in a transaction, that's 2N atomic operations — each one a potential cache-line bounce. Typhon uses epoch-based protection instead: one stamp when entering a transaction scope, one clear when exiting. Pages accessed within an active epoch can't be evicted. Cost: 2 operations per transaction, regardless of how many pages are touched.

Zone maps eliminate entire clusters of indirection. Each indexed field maintains per-cluster min/max bounds. A range query like WHERE Level >= 50 checks two integers per cluster — if the cluster's maximum is below 50, skip every entity in it without loading a single component byte. The impact at different selectivities, measured on 100K entities:

Selectivity	Without zone maps	With zone maps	Speedup
100%	13.4 ms	1.3 ms	10x
50%	13.4 ms	0.65 ms	21x
10%	13.4 ms	0.16 ms	84x
1%	13.4 ms	0.05 ms	268x

The float ordering trick makes this work for non-integer types: an IEEE 754 sign-flip converts floats to a representation where integer comparison order equals numeric order, enabling the same two-comparison interval overlap check regardless of field type.

At the other end of the scale, division elimination saves cycles on every single chunk lookup:

// Field: precomputed at segment creation
// Replaces expensive division (~20-80 cycles) with multiply+shift (~3-4 cycles)
private readonly ulong _divMagic;

// Constructor: compute magic multiplier once
_divMagic = (0x1_0000_0000UL + (uint)_otherChunkCount - 1) / (uint)_otherChunkCount;

// Hot path: every chunk lookup uses this instead of idiv
var pageIndex = (int)((adjusted * _divMagic) >> 32);
var offset = (int)(adjusted - (uint)(pageIndex * _otherChunkCount));

Integer division (idiv on x64) is notoriously slow — 20 to 80 cycles depending on operand size. The magic multiplier replaces it with a multiply and a shift: 3-4 cycles. The precomputation happens once when a segment is created; the benefit repeats on every one of the millions of chunk lookups that follow. Six lines of math, 20x speedup on a hot path. This is a classic systems programming trick that most managed-language developers have never needed — but when your per-entity budget is 2.5 nanoseconds, you need it.

Principle 4: Let the JIT Help

The JIT compiler is your optimization partner, not your enemy. Write code in patterns it can optimize, and it does work for you that you'd have to do manually in C or Rust.

Constrained generics give you monomorphization. When you write where TMask : struct, IArchetypeMask<TMask>, the JIT generates a separate native code path for each concrete type. ArchetypeMask256 (four ulong fields, bitwise operations) gets fully inlined — no vtable, no virtual dispatch. This is the same optimization Rust gets from generics, but opt-in through the struct constraint.

sealed enables devirtualization. DirtyBitmap and ArchetypeClusterInfo are both on hot paths and both sealed. The JIT knows no subclass can exist, so it converts virtual calls to direct calls and can inline them.

[AggressiveInlining] eliminates call overhead on micro-operations. B+Tree binary search, transaction state validation, every lock acquire/release — the overhead of a method call (save registers, set up stack frame, restore) is 2-5 ns. On a path called millions of times, that compounds.

SoA layout enables auto-vectorization. When a cluster is fully occupied (all N slots in use), the iteration loop becomes a simple sequential walk over contiguous SoA arrays with no branches. The JIT can auto-vectorize this on AVX2 — processing 8 floats per SIMD instruction. The SoA layout isn't just about cache locality; it's about giving the JIT a pattern it can vectorize.

But the most surprising JIT trick is dead-code elimination through static readonly fields:

// TelemetryConfig.cs — field declarations
/// <summary>
/// static readonly fields allow the JIT to eliminate disabled telemetry code paths
/// entirely. When a readonly field is false, the JIT treats guarded blocks as dead
/// code and removes them completely in Tier 1 compilation.
/// </summary>
public static readonly bool Enabled;
public static readonly bool EcsEnabled;
public static readonly bool EcsActive;    // Combined: Enabled && EcsEnabled

// Static constructor — computed once at startup
static TelemetryConfig()
{
    var section = config.GetSection("Typhon:Telemetry");
    Enabled = section.GetValue("Enabled", false);
    EcsEnabled = ecsSection.GetValue("Enabled", false);
    EcsActive = Enabled && EcsEnabled;
}

// EcsQuery.cs — usage on hot path
if (TelemetryConfig.EcsActive)
{
    activity = TyphonActivitySource.StartActivity("ECS.Query.Execute");
    activity?.SetTag(TyphonSpanAttributes.EcsArchetype, typeof(TArchetype).Name);
}

When EcsActive is false, the JIT doesn't just short-circuit the branch — it eliminates the entire if block from the generated native code. No branch instruction, no condition check, zero cost. The static readonly field, initialized in a static constructor, is treated as a constant after Tier 1 JIT compilation. The dead branch and everything inside it vanish.

This gives you zero-cost observability. Full OpenTelemetry tracing when enabled; literally nothing — not even a branch — when disabled. Most C# developers don't know the JIT does this. It's worth structuring your telemetry and feature flags around this pattern.

Principle 5: Design for the Hardware

The CPU manual is a requirements document. Cache-line size, SIMD register width, TLB coverage, memory bandwidth — these aren't abstract numbers. They drive struct sizing, batch sizes, and allocation strategy.

Cache-line size (64 bytes on x86, 128 bytes on Apple Silicon) drives CacheLinePaddedInt sizing, B+Tree node alignment, and SoA array alignment. The ViewDeltaRingBuffer aligns each sub-buffer to 64-byte boundaries so that the hardware prefetcher doesn't waste bandwidth loading adjacent unrelated data.

SIMD width determines batch sizes. Typhon's SimdPredicateEvaluator uses three-tier CPU dispatch for filtering entities by field values: AVX-512 processes 16 integer comparisons per instruction, AVX2 processes 8, with a scalar fallback for older hardware. The AVX-512 path uses a workaround — .NET doesn't expose 512-bit gather intrinsics, so it performs two 256-bit AVX2 gathers and combines them into a Vector512 for the comparison step. The JIT emits a native vpcmpd instruction for the 16-wide comparison. On Zen 4 (which double-pumps 512-bit operations), throughput matches two AVX2 iterations but with half the loop overhead.

Software prefetch hides memory latency where it matters most. During HashMap resize, speculative prefetch computes the future entry's position in the resized table and issues Sse.Prefetch0 to start loading that cache line while the current entry is being processed. The JIT translates this to a prefetcht0 instruction — essentially free to issue, and it hides 100+ cycles of latency per entry.

BMI2 instructions accelerate spatial indexing. Morton key encoding (Z-order curves) uses Bmi2.ParallelBitDeposit to interleave X/Y coordinates in ~1 cycle. The scalar fallback costs ~10 cycles. Morton ordering places spatially adjacent grid cells at nearby array indices, improving cache locality during neighbor queries.

TLB coverage constrains working set design. Without 2 MB huge pages, x86 L2 TLB covers only 8-12 MB. Every access beyond that risks a 15-20 ns page walk penalty on top of the data access itself. Typhon's cluster storage keeps 100K entities in ~2.5 MB — comfortably within L2 TLB coverage even without huge pages. For larger datasets, the page cache's 8 KB pages and sequential access patterns keep the hardware prefetcher effective.

Memory bandwidth (~50 GB/s on Zen 4) is the ceiling for bulk scans. If your SoA component scan isn't approaching this number, something is leaving performance on the table — unnecessary indirection, poor alignment, or branches that defeat the prefetcher.

All measurements in this post were taken on an AMD Ryzen 9 7950X with .NET 10, BenchmarkDotNet, release configuration.

The Numbers

Individual principles are nice. What matters is how they compound. Here's what the engine actually delivers:

Operation	Latency
Cluster iteration (per entity)	2.5 ns
CRUD lifecycle (spawn, read, update, destroy, commit)	2.95 μs
Transaction create-read-commit (100 entities)	3.6 μs
B+Tree point lookup (10K entries)	191 ns
Component read (1 MVCC version)	703 ns
Component read (50 MVCC versions)	720 ns
Uncontended RW lock acquire	7.5 ns
Page cache hit	5.5 ns
Chunk accessor MRU hit	1.1 ns
Epoch enter/exit	3.3 ns
Cascade delete 10K entities	7.6 μs

The version invariance number deserves a callout: reading a component with 50 MVCC revisions costs the same as reading one with a single revision. 703 ns vs 720 ns — within measurement noise. The revision chain design works.

These principles also scale to parallel execution:

Workers	Tick time	Speedup	Efficiency
1	~37 ms	1.0x	100%
2	~18 ms	2.1x	104%
4	~10 ms	3.8x	95%
8	~5.3 ms	7.1x	89%

89% parallel efficiency on 8 workers. The 16-worker result (6.7x, 42% efficiency) hits the L3 cache / CCD boundary on the 7950X — a hardware wall, not a software one.

To put these numbers in perspective, here's the concurrency cost hierarchy that drives Typhon's design decisions:

Level	Cost	Example
0: Thread-local	~2 ns	TLS counter, local variable
1: Uncontended atomic	5-10 ns	AccessControl read latch
2: Contended atomic	20-140 ns	Multiple writers, same lock
3: System call	500-1000 ns	Timestamp via syscall
4: Context switch	~10,000 ns	Blocking lock, futex wait
5: Oversubscription	100,000+ ns	More threads than cores

Each level is roughly 10x more expensive than the previous one. Typhon's AdaptiveWaiter (spin → yield → sleep progression) keeps most contention at Level 2, avoiding the 100x jump to Level 4. The cache-line padding from Principle 1 keeps parallel workers from bouncing each other between Level 1 and Level 2. Every design decision maps to staying as low in this hierarchy as possible.

Trade-offs

Unsafe is unsafe. These techniques require unsafe code — pointer arithmetic, raw memory access, manual layout control. One bug can corrupt the page cache. Roslyn analyzers catch some classes of errors at compile time, but not all. The safety net has holes.

Complexity budget. Magic multipliers, SIMD evaluators, epoch-based protection, zone maps — each one is simple in isolation. The combination creates a codebase that demands systems-level understanding to navigate. There's no shortcut around understanding the hardware.

Not all of this transfers. Most .NET applications don't need microsecond latency. Using CacheLinePaddedInt in a web API is premature optimization. These techniques are for when you've measured, profiled, and confirmed that memory access patterns are your bottleneck — not before.

What's Next

The next post dives into concurrency: "Deadlock-Free by Construction: How Typhon Eliminates Deadlocks Instead of Detecting Them." Most databases treat deadlocks as a runtime problem — detect the cycle, abort a transaction, retry. Typhon makes deadlocks structurally impossible through a three-pillar mathematical argument. No detection, no timeouts, no retries.

What Game Engines Know About Data That Databases Forgot

Loïc Baumann — Sun, 05 Apr 2026 22:20:39 +0000

💡Typhon is an embedded, persistent, ACID database engine written in .NET that speaks the native language of game servers and real-time simulations: entities, components, and systems.

It delivers full transactional safety with MVCC snapshot isolation at sub-microsecond latency, powered by cache-line-aware storage, zero-copy access, and configurable durability.

Series: A Database That Thinks Like a Game Engine

Why I'm Building a Database Engine in C#

What Game Engines Know About Data That Databases Forgot (this post)

Microsecond Latency in a Managed Language (coming soon)

Game servers sit at an uncomfortable intersection. They need the raw throughput of a game engine — tens of thousands of entities updated every tick. But they also need what databases provide: transactions that don't corrupt state, queries that don't scan everything, and durability that survives crashes.

Today, game server teams pick one side and hack around the other. An Entity-Component-System framework for speed, with manual serialization to a database for persistence. Or a database for safety, with an impedance mismatch every time they touch game state.

Typhon draws from both traditions. It's a database engine that stores data the way game engines do — and provides the guarantees that game servers need. Here's why those two worlds aren't as far apart as they look.

Two Fields, One Problem

ECS architecture evolved in game engines. Relational databases evolved in enterprise software. They never talked to each other. But look at what they built:

ECS Concept	Database Concept	Shared Principle
Archetype	Table	Homogeneous, fixed-schema storage
Component	Column	Typed, blittable, bulk-iterable data
Entity	Row	Identity with dynamic composition
System	Query	Process all records matching a signature
Frame Budget (16ms)	Latency SLA	Hard real-time deadline

An ECS "archetype" is a table. A "component" is a column. A "system" is a query. The vocabulary is different, the underlying structure is the same. Two fields, separated by decades and industry boundaries, converged on structurally identical solutions because they were solving the same fundamental problem: managing structured data under performance constraints.

This convergence is why a synthesis is possible at all. It's not an accident — it's driven by the same physics. Data must be laid out for the CPU cache. Access patterns must be predictable. Latency budgets are real.

What We Learned From Game Engines

ECS taught the database world something important about how data should be stored. Three lessons Typhon draws directly from game engine architecture:

Cache locality by default. In a traditional row store, reading all player positions means loading entire rows — names, inventories, health, everything. Most of those bytes are wasted. In ECS, components are stored per type: all positions contiguous, all health values contiguous. Reading 10,000 positions is a linear memory scan where every byte is useful.

This matters more than most developers realize. An L1 cache hit costs roughly 1 nanosecond. A DRAM miss costs 60-70 ns — a 65x penalty. When your database layout forces cache misses, no amount of algorithmic cleverness can save you.

Zero-copy is the default, not the optimization. In a traditional database, reading a record means deserializing from a storage page into a language-level object. In ECS, a component is already in memory in its final layout — you just hand back a pointer. Typhon preserves this: components are blittable unmanaged structs read directly from pinned memory pages. No serialization, no managed heap allocation, no GC involvement.

Entity as pure identity. In ECS, an entity is just an ID — a 64-bit number with no inherent structure. All data lives externally in component tables. This is the opposite of ORM thinking where the object is the entity. Typhon inherits this: EntityId is a lightweight value type, all state lives in typed component storage. This separation is what makes the rest of the architecture possible — per-component versioning, per-component storage modes, independent indexes per component type.

What We Learned From Databases

Traditional databases solved problems that ECS never had to face. Four capabilities Typhon draws from database architecture:

ACID transactions with per-component MVCC. Game engines typically have no isolation. Two systems modifying the same entity in the same tick is a race condition — and in a single-process game, you control the execution order so you can manage it. On a game server with concurrent player sessions, you can't.

Databases solved this decades ago with MVCC: snapshot isolation where readers never block writers, with conflict detection at commit time. Typhon brings this in — but with a twist. Traditional databases version entire rows. Typhon versions each component independently. An entity's PositionComponent and InventoryComponent each maintain their own revision chain: a circular buffer of 12-byte revision entries, each stamped with a 48-bit transaction sequence number.

// Simplified: finding the visible revision for a snapshot
foreach (var rev in WalkRevisions(entityId))
{
    if (rev.IsolationFlag && rev.TSN != myTransactionTSN)
        continue;  // Skip uncommitted revisions from other transactions

    if (rev.TSN <= snapshotTSN)
        return rev; // Most recent revision visible to our snapshot
}

This means a transaction reading a player's position sees a consistent frozen point-in-time across all component types simultaneously — without locking any of them. Writers never block readers. And because revisions are per-component rather than per-entity, updating a player's position doesn't create a new version of their inventory. Less data copied, less garbage to collect.

Indexed selective access. This is the big one. ECS systems iterate everything matching a component signature every tick. That works brilliantly for particle simulations where every particle needs updating. But game servers often don't need all of them:

Scenario	Total Entities	Processed Per Tick	Useful Work
Battle royale (per-client relevancy)	50,000 actors	500–2,000	1–4%
MMO area of interest	100,000	200–1,000	0.2–1%
Physics (awake bodies only)	All rigidbodies	Awake subset	5–20%

When you're processing 1–4% of your entities, scanning everything is doing 25–100x more work than necessary. ECS frameworks recognized this — Unity DOTS added enableable components, Flecs added group_by, Unreal MassEntity added LOD tiers. These are all clever workarounds for the same underlying issue: ECS was designed for bulk iteration, not selective access.

Databases solved this with indexes. B+Trees for value-based lookups, spatial trees for area-of-interest queries, selectivity estimation to decide when to scan versus when to seek. Typhon brings these into the component storage model — not as bolted-on workarounds, but as first-class citizens.

Spatial partitioning. For spatial access patterns specifically — the #1 selective access need in game servers — Typhon integrates a two-layer spatial index directly into the component storage:

Layer 1: Sparse hash map — maps coarse grid cells to entity counts. O(1) rejection of empty regions before the tree is even touched.
Layer 2: Page-backed R-Tree — AABB, radius, ray, frustum, and kNN queries. Same OLC-latched, SOA node architecture as the B+Trees.

Both layers run inside the same transactional model as everything else. No external spatial hash bolted on alongside your ECS. No cache locality destroyed by chasing pointers into a separate data structure.

Durability. A game client can afford to lose state on crash — reload the level. A game server cannot. Player inventories, economy state, progression data — all must survive process restarts and crashes. WAL-based crash recovery, checkpointing, configurable fsync — these are database fundamentals that game servers need but ECS frameworks never provided.

Query planning. When you have both indexes and sequential storage, someone needs to decide which access path to use. Databases have decades of work on cost-based query optimization — selectivity estimation, histogram statistics, index selection. Typhon brings a query planner into the ECS world: given a predicate on a component field, it automatically chooses full scan or B+Tree seek based on estimated selectivity.

Purpose-Built for Game Servers

Typhon doesn't glue ECS and database concepts together with duct tape. It synthesizes them into a single model designed for game server workloads.

A component in Typhon is simultaneously an ECS component and a database schema:

[Component]
public struct PlayerComponent
{
    [Field]
    public String64 Name;

    [Field]
    [Index]                    // B+Tree for fast lookups
    public int AccountId;

    [Field]
    public float Experience;
}

Blittable, unmanaged, fixed-size, stored contiguously per type — that's the ECS side. Typed fields with automatic B+Tree indexes on marked fields — that's the database side. One declaration, both worlds.

The query API makes the synthesis concrete:

var topPlayers = db.Query<Player>()
    .Where(p => p.Level >= 50)
    .OrderByDescending(p => p.Level)
    .Take(10)
    .ExecuteOrdered(tx);

ECS-style typed component access. Database-style predicate filtering with automatic index selection. Inside a transaction with snapshot isolation. The query planner chooses scan vs B+Tree based on selectivity — the developer doesn't have to.

And because game servers have different durability needs for different operations, Typhon lets you choose per unit of work:

// Position ticks: game-engine speed, batched durability
using var uow = dbe.CreateUnitOfWork(DurabilityMode.Deferred);

// Legendary item drop: database safety, immediate fsync
using var uow = dbe.CreateUnitOfWork(DurabilityMode.Immediate);

Same engine, same API. Deferred mode gives game-engine-class commit latency for position updates that can be re-simulated on crash. Immediate mode gives database-class guarantees for a transaction that grants a rare item worth real money. The game server decides per operation — not globally.

Storage Modes: Not All Data Is Equal

A game server doesn't treat all data the same. Player positions change 60 times per second and can be re-simulated on crash. Inventory mutations are rare but must never be lost. AI runtime state — current targets, threat scores, pathfinding waypoints — is recomputed every tick and worthless after a restart.

Traditional databases treat all data identically. Traditional ECS keeps everything in memory with no durability distinction. Typhon lets you choose per component type:

Mode	MVCC History	Persisted	Change Tracking	Best For
Versioned	Full revision chains	Yes (WAL + checkpoint)	Via MVCC	Inventory, economy, progression
SingleVersion	Current state only	Yes (WAL + checkpoint)	DirtyBitmap	Positions, health, frequently-updated state
Transient	Current state only	No	DirtyBitmap	AI blackboard, threat scores, pathfinding scratch

SingleVersion components skip the revision chain overhead entirely — no circular buffer, no per-write allocation. They track changes through a DirtyBitmap instead: one bit per entity, flipped on write, scanned on tick fence. This is how game engines track what changed, and it's the right model for data that updates every tick.

Versioned components get full MVCC with snapshot isolation — readers see consistent historical state, writers don't block readers, conflicts are detected at commit time. This is how databases protect critical data, and it's the right model for things that must never be corrupted.

Transient components never touch disk at all — no WAL, no checkpoint, no recovery. Pure in-memory storage with the same query and indexing API as everything else. AI blackboard data that's recomputed every tick has no business paying persistence overhead.

The same engine, the same transaction API, but the storage layer does exactly what each component type needs. This is what "purpose-built for game servers" means in practice.

Views: The Bridge Between ECS Systems and Database Queries

In ECS, a "system" runs every tick, processing all matching entities. In a database, a "materialized view" maintains a cached result set and refreshes it incrementally. Typhon's Views are both:

using var view = db.Query<ItemData>()
    .Where(i => i.Rarity >= 3)
    .ToView();

// Game loop
while (running)
{
    using var tx = dbe.CreateQuickTransaction();
    view.Refresh(tx);  // Microsecond incremental refresh

    // React to changes — like an ECS system, but only for what changed
    var delta = view.GetDelta();
    foreach (var pk in delta.Added)   SpawnVisual(pk);
    foreach (var pk in delta.Removed) DespawnVisual(pk);
    foreach (var pk in delta.Modified) UpdateVisual(pk);
    view.ClearDelta();
}

The initial ToView() runs a full query. After that, Refresh() drains a lock-free ring buffer of changes pushed by the commit path — only entities whose indexed fields actually changed are re-evaluated. If 100,000 entities match your view but only 12 changed since last refresh, you do 12 evaluations, not 100,000.

This is the iterate-everything problem solved from the database side: don't re-scan, track deltas.

Trade-offs

Specializing for game servers means giving things up.

Blittable components only. No string, no object references, no variable-length arrays inside components. Text uses fixed-size types like String64. This is the price of zero-copy reads and cache-friendly storage — and it's a constraint game developers are already familiar with from ECS frameworks.

Entity-centric relationships, not SQL JOINs. Typhon supports navigation links, 1:N and N:M relationships — but they follow entity references, closer to a graph database than a traditional SQL one. This matches how game servers naturally think about data (an entity has components, a guild contains members), but if your mental model is SELECT ... FROM a JOIN b ON a.x = b.y, it's a different paradigm.

Schema in code, not SQL. Components are C# structs with attributes, not DDL statements. Natural for game developers, unfamiliar territory for database administrators. If your team thinks in SQL, this is a paradigm shift.

What's Next

In the next post, I'll go deeper into the performance philosophy that makes all of this actually fast — data-oriented design, cache-line awareness, and zero-allocation hot paths. The principles that let a managed language hit microsecond-latency transactions.

If you want to follow along, the best way is to star the repo or subscribe to the RSS feed.

Why I'm Building a Database Engine in C#

Loïc Baumann — Sun, 29 Mar 2026 13:02:55 +0000

When I tell people I'm building an ACID database engine in C#, the first reaction is always the same: "But what about GC pauses?"

It's a fair question. Nobody builds high-performance database engines in .NET. The assumption is that you need C, C++, or Rust for this class of software — that managed languages are fundamentally disqualified from the microsecond-latency club.

After 30 years of building real-time 3D engines and systems software, I chose C# anyway. The project is called Typhon: an embedded ACID database engine targeting 1–2 microsecond transaction commits. And the reasons behind that choice might change how you think about what C# can do.

The Case Against C# (Let's Steel-Man It)

Before I make my case, let me honestly lay out every argument against choosing C# for this. These are real concerns, not strawmen.

The GC is non-deterministic. It can pause all your threads whenever it wants. For a database engine that promises microsecond latency, a 10ms Gen2 collection is catastrophic — that's 10,000x your latency budget.

You don't control memory layout. The managed heap decides where objects live. The GC can move them around during compaction. You can't guarantee that your B+Tree nodes sit on cache-line boundaries, or that your page cache buffer won't get relocated mid-transaction.

JIT warmup is real. The first call to any method pays the compilation cost. In a database engine, the first transaction after startup shouldn't be 100x slower than the steady state.

Virtual dispatch and bounds checking add overhead. Every array access has a hidden bounds check. Every interface call goes through a vtable. In a hot loop processing millions of entities, these nanoseconds compound.

These are all legitimate problems. I won't pretend they aren't. But here's what most people miss: modern C# has answers for every single one of them.

What Most People Don't Know About C

The C# that most developers know — classes, garbage collection, LINQ — is only half the language. There's a whole other side that the .NET runtime team has been quietly building for a decade, and it looks nothing like what you'd expect.

unsafe gives you C-level control. Raw pointers, pointer arithmetic, stackalloc for stack buffers, fixed-size arrays — the JIT generates the same mov/cmp/jne instructions you'd get from C. Not "close to C." The same instructions.

GCHandle.Alloc(Pinned) makes the GC irrelevant where it matters. You can pin byte arrays so the GC never moves them. Typhon's entire page cache is pinned memory — the GC doesn't touch it, doesn't scan it, doesn't move it. It's just raw bytes at a fixed address, exactly like malloc in C.

ref struct eliminates heap allocations on hot paths. A ref struct can never escape to the heap. It lives on the stack, dies when the scope ends, and the GC never knows it existed. Typhon's entity accessor (EntityRef) is a 96-byte ref struct — zero allocation, zero GC pressure.

Constrained generics give you true monomorphization. When you write where T : unmanaged, the JIT generates a separate native code path for each type parameter. sizeof(T) becomes a constant. Dead branches get eliminated. It's the same optimization Rust gets from generics — not a runtime dispatch, but compile-time specialization.

Hardware intrinsics are first-class. System.Runtime.Intrinsics gives you Vector256, Sse42.Crc32, BitOperations.TrailingZeroCount — the same SIMD instructions available in C/C++, with the same performance, and runtime feature detection so you can fall back gracefully.

[StructLayout(Explicit)] gives you exact memory layout. Field offsets, padding, size — you control every byte. Cache-line alignment, false-sharing prevention, bit-packing — it's all there.

This isn't "C# trying to be C." It's C# providing a genuine systems programming layer on top of a best-in-class managed ecosystem.

What Typhon Actually Looks Like

Theory is nice, now let's look at real code.

Hardware-accelerated WAL checksums

Every page written to the Write-Ahead Log needs a CRC32C checksum. Here's what that looks like in C# — calling CPU instructions by name:

private static uint ComputePartial(uint crc, ReadOnlySpan<byte> data)
{
    if (Sse42.X64.IsSupported)   return ComputeSse42X64(crc, data);
    if (Sse42.IsSupported)       return ComputeSse42X32(crc, data);
    if (ArmCrc32.Arm64.IsSupported) return ComputeArm64(crc, data);
    return ComputeSoftware(crc, data);
}

private static uint ComputeSse42X64(uint crc, ReadOnlySpan<byte> data)
{
    ulong crc64 = crc;
    ref byte ptr = ref MemoryMarshal.GetReference(data);
    int offset = 0;
    int aligned = data.Length & ~7;

    while (offset < aligned)
    {
        crc64 = Sse42.X64.Crc32(crc64, Unsafe.ReadUnaligned<ulong>(ref Unsafe.Add(ref ptr, offset)));
        offset += 8;
    }

    uint crc32 = (uint)crc64;
    while (offset < data.Length)
    {
        crc32 = Sse42.Crc32(crc32, Unsafe.Add(ref ptr, offset));
        offset++;
    }
    return crc32;
}

Sse42.X64.Crc32() compiles to a single x86 crc32 instruction. The runtime detects the CPU capabilities, the JIT eliminates the dead branches, and what executes is the same code a C programmer would write — but with automatic fallback on platforms without SSE4.2. Result: ~1.3 µs per 8 KB page.

The SIMD chunk accessor

This is Typhon's page cache hot path — a 16-slot cache that finds your data in one of three tiers:

// === ULTRA FAST PATH: MRU check ===
var mru = _mruSlot;
if (_pageIndices[mru] == pageIndex)
{
    var headerOffset = pageIndex == 0 ? _rootHeaderOffset : _otherHeaderOffset;
    return (byte*)_baseAddresses[mru] + headerOffset + offset * _stride;
}

// === FAST PATH: SIMD search through all 16 cached slots ===
fixed (int* indices = _pageIndices)
{
    var target = Vector256.Create(pageIndex);

    var v0 = Vector256.Load(indices);
    var mask0 = Vector256.Equals(v0, target).ExtractMostSignificantBits();
    if (mask0 != 0)
    {
        var slot = BitOperations.TrailingZeroCount(mask0);
        return GetFromSlot(slot, pageIndex, offset, dirty);
    }

    var v1 = Vector256.Load(indices + 8);
    var mask1 = Vector256.Equals(v1, target).ExtractMostSignificantBits();
    if (mask1 != 0)
    {
        var slot = 8 + BitOperations.TrailingZeroCount(mask1);
        return GetFromSlot(slot, pageIndex, offset, dirty);
    }
}

The _pageIndices array is a fixed int[16] — 64 bytes, one cache line, packed for SIMD. One Vector256.Equals compares 8 page indices in a single instruction. The MRU fast path handles the common case (repeated access to the same page) with a single branch — branch predictor friendly, near-zero cost.

Zero-copy entity reads

EntityRef is a ref struct — stack-only, 96 bytes, with an inline fixed array caching component locations:

public unsafe ref struct EntityRef
{
    internal readonly EntityId _id;
    internal readonly ArchetypeMetadata _archetype;
    internal readonly ArchetypeEngineState _engineState;
    internal readonly Transaction _tx;
    internal ushort _enabledBits;
    internal readonly bool _writable;
    private fixed int _locations[16];  // inline component chunk IDs

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public ref readonly T Read<T>(Comp<T> comp) where T : unmanaged
    {
        byte slot = _archetype.GetSlot(comp._componentTypeId);
        int chunkId = _locations[slot];
        var table = _engineState.SlotToComponentTable[slot];
        return ref _tx.ReadEcsComponentData<T>(table, chunkId);
    }
}

That Read<T> call goes from method call → slot lookup → chunk ID → page cache → pointer arithmetic → ref readonly T pointing directly into a pinned memory page. Zero copies. Zero allocations. Zero GC involvement. The where T : unmanaged constraint means the JIT knows the exact layout — it compiles to pointer arithmetic, nothing more.

JIT-specialized hash functions

Even the hash functions exploit the JIT. Since sizeof(TKey) is a compile-time constant for constrained generics, the dead branches vanish:

[MethodImpl(MethodImplOptions.AggressiveInlining)]
internal static uint ComputeHash<TKey>(TKey key) where TKey : unmanaged
{
    if (sizeof(TKey) == 4) return FastHash32(Unsafe.As<TKey, uint>(ref key));
    if (sizeof(TKey) == 8) return XxHash32_8Bytes(Unsafe.As<TKey, long>(ref key));
    return XxHash32_Bytes((byte*)Unsafe.AsPointer(ref key), sizeof(TKey));
}

When you call ComputeHash<int>(42), the JIT generates just the 4-byte path. The other two branches are completely eliminated. This is real monomorphization, not runtime dispatch.

The Productivity Argument

A database engine is more than its hot path. Around the core engine sits a large shell of infrastructure: configuration management, structured logging, telemetry, dependency injection, testing, benchmarking.

In C or Rust, you'd build much of this yourself or stitch together crates/libraries with varying quality. In .NET, this is production-grade and free: ILogger and OpenTelemetry for observability, BenchmarkDotNet for rigorous micro-benchmarks, NUnit for testing, IConfiguration for settings. All well-documented, all interoperable, all maintained by Microsoft or battle-tested OSS communities.

For a solo developer building a database engine, this is a genuine competitive advantage. I spend my time on concurrency primitives and page cache eviction, not on reinventing a logging framework.

It's the Memory Layout, Not the Language

Here's the insight that years of real-time 3D engines taught me: the bottleneck in a database engine is memory access patterns, not instruction throughput.

A cache miss to DRAM on a Ryzen 7950X costs 61–73 nanoseconds. That's ~250 CPU cycles doing nothing, waiting for data. A CAS operation hitting L1 costs 1.4 nanoseconds. The ratio is 50:1.

No amount of "zero-cost abstractions" in your language can save you if your data structures cause cache misses. Conversely, if your data layout is cache-friendly — contiguous, aligned, predictable access patterns — the language barely matters. C# with unsafe generates identical machine code to C on hot paths. The JIT is that good.

What matters is:

Cache-line awareness: Typhon's B+Tree nodes are 128 bytes — two cache lines. The stride prefetcher on Zen4 covers the second line automatically. This alone cut insert latency by 53% and lookup latency by 30% versus 64-byte nodes.
Data-oriented design: Structure of Arrays over Array of Structures. SIMD-friendly layouts. Blittable types only.
Minimizing indirections: Every pointer chase is a potential cache miss. The SIMD chunk accessor's MRU hit avoids the chase entirely.

The language you write in matters far less than the memory layout you design.

The Numbers

All measurements on a Ryzen 9 7950X, .NET 10.0, BenchmarkDotNet, release configuration.

Operation	Latency	Throughput
CRUD lifecycle MVCC (spawn, read, update, destroy, commit)	1.2 µs	830K ops/sec
90 reads/10 updates workload (100 ops per tx, MVCC)	22 µs	~4.5M entity-ops/sec
B+Tree lookup (hit)	267 ns	3.7M ops/sec
B+Tree sequential scan (per key)	2.1 ns	479M keys/sec
Uncontended lock acquire	7.8 ns	128M ops/sec
Page cache hit	5.3 ns	—

Context: an uncontended CAS on Zen4 costs 1.4 ns. A DRAM round-trip costs 61–73 ns. Typhon's lock acquire (7.8 ns) is about 5 CAS operations — tight, considering it handles shared/exclusive arbitration with waiter tracking. The 267 ns B+Tree lookup implies 6–7 memory accesses, which matches a tree traversal through L2/L3 cache.

These are early alpha numbers. There's room to improve. But they validate the core thesis: C# is not the bottleneck.

Trade-offs

No choice is without cost. Here's what I'd tell someone considering the same path.

Memory safety is on you. In unsafe blocks, you can corrupt memory, dereference bad pointers, overflow buffers — the compiler won't save you. Span<T> is a slightly slower but totally safe alternative.

The GC hasn't been a problem — but it could be. By pinning the page cache and using ref struct on hot paths, Gen2 collections are rare and cheap. But I won't pretend this is guaranteed. A workload that allocates heavily in managed code between transactions could still see pauses. The answer is discipline: don't allocate on hot paths. The language lets you — it just doesn't force you.

"But Rust would give you compile-time safety." True — the borrow checker catches ownership and lifetime bugs that unsafe C# can't. But C# has a trick Rust doesn't: Roslyn analyzers. I wrote a custom analyzer suite (TYPHON001–007) that enforces domain-specific safety rules as compiler errors:

[NoCopy] attribute + analyzer: performance-critical structs like ChunkAccessor cannot be passed by value — the compiler errors if you forget ref. This is the same guarantee Rust's borrow checker gives for move semantics, but scoped to the types that actually matter.
Ownership tracking: if you create a ChunkAccessor or Transaction and don't dispose it, that's a compiler error — not a runtime leak. The analyzer tracks ownership transfers through assignments, returns, and ref/out parameters, [return: TransfersOwnership] on a method helps to express ownership transfer for the analyzer to act accordingly.
Disposal completeness: if your type holds a critical disposable field and your Dispose() method misses it or has an early return that skips it — compiler error.

// This is a compile-time error in Typhon — TYPHON001
void Process(ChunkAccessor accessor) { ... }  // ✗ Error: must be passed by ref

void Process(ref ChunkAccessor accessor) { ... }  // ✓ OK

You don't get Rust's safety for free in C#. But you can build the exact subset you need as compiler errors, tailored to your domain. And unlike Rust's borrow checker, these rules carry domain context in the diagnostics: "causes page cache deadlock" is more actionable than "value moved here."

Rust's ecosystem for the surrounding infrastructure (logging, DI, configuration, testing) is also less mature than .NET's, and as a solo developer, my velocity matters. I chose the language where I ship faster.

JIT warmup is real but manageable. The first few transactions after cold start are slower. For an embedded engine (no separate server process), this is acceptable — the host application typically has its own warmup. For a server database, you'd want tiered compilation or AOT.

What's Next

In the next post, I'll explain why an ACID database engine borrows its storage architecture from game engines — specifically the Entity-Component-System pattern. Game engines and databases are solving the same fundamental problem: managing structured data with extreme performance constraints. They just evolved completely different solutions.

If you want to follow along, the best way is to star the repo or subscribe to the RSS feed.

This is Post #1 in a series about building a database engine in C#. Next up: "What Game Engines Know About Data That Databases Forgot".