I spent weeks building an R-Tree for my database engine. It ships turned off. A flat array scan beat it, 1.4-1.75x faster overall. The tree does far less work. But CPUs don't charge you for work, they charge you for waiting. nockawa.github.io/blog/the-rtr...
The R-Tree We Built and Turned Off
Typhon's spatial index can promote a dense cell from a linear scan to a per-cell R-Tree. It ships with that promotion disabled — the threshold is int.MaxValu...
nockawa.github.io
Most backends keep two stores: one they trust, one they can afford to read. Something copies between them. Typhon is one store. Your struct IS the row. ACID transactions and your systems run in-process. A database and a compute engine: www.typhondb.io/deck/typhon-intro/ #dotnet #gamedev #database
Typhon — a database and a compute engine, in one process
Full ACID transactions. Microsecond latency. An ECS data model built for real-time systems. An 8-slide technical intro.
typhondb.io
Every database has a primary key index. Almost all are trees. We deleted ours. A B+Tree's shape exists to keep keys in order. Nothing ever asked ours for one — an entity id is a handle you can't query on. ~4x measured. nockawa.github.io/blog/why-we-... #dotnet #gamedev
Why We Eliminated the Primary Key B+Tree
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 ...
nockawa.github.io
A reader-writer lock: counter, 3 waiter classes, owning thread id, contention flag, full state machine - packed into one ulong. Every transition is one CompareExchange. 19ns uncontended, zero allocation, never touches the kernel. nockawa.github.io/blog/the-8-b... #dotnet #csharp #database
The 8-Byte Lock: Packing a Reader-Writer Lock Into 64 Bits
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, ...
nockawa.github.io
You want to know your quota usage (on track, behind, ahead), if the service is up and running or having issue, your extra usage. There's a dotnet tool for that now: dotnet tool install --global ClaudeUsage Then just call: claude-usage Github repo: github.com/nockawa/Clau...
Classic MVCC copies the whole row when you change one field. Typhon versions individual components instead — change one, the rest of the record stays put. Snapshot-isolated reads at ~80 ns. nockawa.github.io/blog/mvcc-at... #dotnet #csharp #database
MVCC at Microsecond Scale: Snapshot Isolation Without Cloning Rows
Classic MVCC clones the whole row on every update. Typhon versions individual components — an entity with eight components that changes one appends a single ...
nockawa.github.io
Stop counting, start timing. Typhon's page cache did 2N atomic ops per transaction to protect live pages. I replaced it with epoch-based reclamation (à la RCU): pin time on entry, one tick on exit. Flat 3.5 ns — 1 page or 10,000. nockawa.github.io/blog/page-ca...
Building a Page Cache That Doesn't Count: Epoch-Based Memory Management
Traditional page caches reference-count every page access — two atomic operations per page, per transaction, on counters that bounce between cores. Typhon re...
nockawa.github.io
Great tech isn't enough — you need the tools to use it. I built an ACID database engine in .NET, then couldn't see inside it. I built the Workbench for devs & ops: operate, troubleshoot, profile. Blog post: 📝 nockawa.github.io/blog/a-datab... #dotnet #csharp #DatabaseEngineering #DeveloperTools
Typhon Workbench intro
YouTube video by Log2n
youtube.com
Most databases pick a durability strategy at boot. Typhon picks one per commit. 10K NPC updates at ~1-2µs, one legendary drop at ~15-85µs, same engine, same WAL. Three modes, ONE writer. #database #gamedev #systems https://nockawa.github.io/blog/three-durability-modes-one-wal/
Three Durability Modes, One WAL
How Typhon lets a single transaction choose between volatile, group-committed, or immediate-FUA durability — same WAL, same engine, per-commit override.
nockawa.github.io
Most databases detect deadlocks at runtime and abort a victim. Typhon ships without a detector—three structural decisions make a lock-dependency cycle architecturally impossible. #database #concurrency #systems https://nockawa.github.io/blog/deadlock-free-by-construction/
Deadlock-Free by Construction
Why Typhon ships without a deadlock detector — three structural decisions that make lock-dependency cycles architecturally impossible.
nockawa.github.io
How do you hit 1-2µs transaction commits in .NET? Five principles: control memory layout, kill heap allocs, reduce indirection, help the JIT, design for the cache. Concrete numbers. #dotnet #performance #systems https://nockawa.github.io/blog/microsecond-latency-managed-language/
Microsecond Latency in a Managed Language
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.
nockawa.github.io
Game engines and databases solved the same problem differently. SpacetimeDB argued ECS→DB. Typhon took the reverse: DB→ECS, using ECS architecture as the storage layer for an ACID database. #gamedev #database #ecs https://nockawa.github.io/blog/what-game-engines-know-about-data/
What Game Engines Know About Data That Databases Forgot
Game engines and databases solved the same problem independently. Typhon draws from both traditions to build a database engine purpose-built for game servers.
nockawa.github.io
Building an ACID database in C# sounds insane—GC, no memory control. Except: unsafe C# emits the same code as C, and the .NET ecosystem comes free. Why I picked .NET over Rust. #dotnet #csharp #database https://nockawa.github.io/blog/why-building-database-engine-in-csharp/
Why I'm Building a Database Engine in C#
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.
nockawa.github.io