Zig and Rust in Production (ft. Matklad)

Tiger Beetle’s speed and reliability come from a deliberately narrow design: it hardcodes a double-entry accounting schema, runs a single-threaded request loop, batches work in large chunks (8,000 transfers), and treats local disk as untrustworthy—repairing corrupted state using a six-replica cluster. The result is a database built for high-performance financial transfers where reliability matters more than general-purpose flexibility.

Instead of relying on migrations or a relational/SQL model, Tiger Beetle encodes the accounting structure directly into the storage engine. That choice removes whole classes of operational complexity and lets the system focus on the hardest requirements of financial transfer: fast, durable, and correct movement of value between accounts. The architecture also follows safety-critical engineering principles associated with NASA’s “power of 10” rules: everything has explicit limits, memory is allocated up front based on command-line configuration, and dynamic allocation is avoided so performance stays predictable and failures don’t cascade.

The system’s distributed consensus design is tuned around availability and failure patterns. Replication durability uses a smaller quorum (three replicas acknowledge), while view-change leadership uses a larger quorum (four replicas) to ensure quorum intersection. With a cluster size of six, that structure supports tolerating multiple failures while avoiding the cost of replicating to four for every write. The key insight is that real-world failures often happen one node at a time; in a four-of-six moment, the cluster is likely still available even if the primary is among the remaining nodes.

Performance isn’t pursued by scaling out across many machines. Horizontal scalability is treated as a poor fit for the workload shape Tiger Beetle targets: financial transfers contend heavily on a small set of “hot” accounts (often summary or auxiliary accounts). Locking two accounts per transfer and sharding by source account can force sequential bottlenecks and even extra network movement of balances between machines. In that setting, a single fast thread can beat distributed systems—an argument reinforced by a cited “scalability but at what cost” line of research.

Language choice ties directly to these constraints. Zig is favored because static, explicit memory management aligns naturally with the “limit everything” approach, and because Zig’s design avoids Rust’s heavy reliance on lifetimes/traits/macros for this style of systems programming. Rust’s borrow checker can prevent certain classes of memory bugs and makes concurrency safer, but Tiger Beetle’s single-threaded core reduces the concurrency advantage; the bigger question is whether Rust can replicate Zig’s fully static, manually managed architecture without turning lifetimes into a maintenance burden.

Finally, Tiger Beetle’s testing philosophy leans on randomized testing (including assertion-driven invariants) rather than only example-based unit tests. The system runs full multi-replica simulations, throws large streams of random operations, and uses internal invariants so incorrect behavior tends to trigger crashes early—making hard-to-reproduce storage and consensus bugs discoverable. Unit tests still matter for business-logic correctness and regression debugging, but randomized simulation is the main engine for finding failures in the complex parts of the system.

Overall, Tiger Beetle’s “amazingness” is less about clever tricks and more about disciplined constraints: hardcoded accounting, explicit limits, batching, distrust of disk, carefully chosen quorums, and a testing strategy built to stress the hardest failure modes.