Hello there, I'm Loïc Baumann Welcome to my site I talk about programming
Every database has a primary key index, and almost every one of them is a tree. Typhon's was too — until we noticed that nothing had ever asked it for a key in order. A query in this engine can only filter on an indexed component field, and an entity id is not one, so the primary key was doing exact-match lookups and nothing else. This is what a B+Tree charges you for ordering, and what happens…
A reader-writer lock with a shared counter, three classes of waiter, an owning thread id, a contention flag and a state machine — all inside a single ulong, published with one CompareExchange. The bit layout, the measured 19 ns, the fairness ladder that keeps writers from starving, and why a lock that gets written to disk is worth building a second, smaller one for.
Classic MVCC clones the whole row on every update. Typhon versions individual components — an entity with eight components that changes one appends a single revision, not eight. How per-component revision chains, a one-byte visibility contract, and grace-period cleanup keep snapshot-isolated reads fast and nearly flat no matter how many times a value has changed.
Traditional page caches reference-count every page access — two atomic operations per page, per transaction, on counters that bounce between cores. Typhon replaces counting with epoch-based reclamation: two operations total, flat, no matter how many pages a transaction touches. The mechanism, the measured cost (3.5 ns), and the one place pure epochs weren't enough.
The Typhon Workbench is the one tool developers and ops keep open to understand a Typhon system — its schema, its data, its behavior — whether it lives in a file, a captured trace, or a live engine. This post opens with the schema-and-data side.
How Typhon lets a single transaction choose between volatile (~1-2µs), group-committed (~1-2µs amortized), or immediate-FUA (~15-85µs) durability — same WAL, same engine, per-commit override.
Why Typhon ships without a deadlock detector — three structural decisions that make lock-dependency cycles architecturally impossible, and why that bet was made before any code was written.
Five design principles that let a C#/.NET database engine hit sub-microsecond transaction latency — from cache-line-aware structs to JIT-eliminated dead code.
Game engines and databases solved the same problem independently. Typhon draws from both traditions to build a database engine purpose-built for game servers.
Everyone says you need C, C++, or Rust for a high-performance database engine. I chose C# — here's why that's not as crazy as it sounds.