I’ve been working on Zeno, an embedded key-value storage engine written in pure Zig.
It started as two separate learning projects into database storage internals and the Adaptive Radix Tree (ART). I liked the results, and had the idea to join them into a standalone engine that I’ve been building in my spare time.
Current design
- ART index with SIMD-optimized node transitions (Node4 → Node256)
- 256 shards architecture: each shard owns its own ART, lock, and memory arena
- WAL with batched-async durability and snapshot-backed recovery
Latest numbers on Ryzen 7 5700X, 32GB DDR4 @ 3200MHz
| Operation | Throughput | p50 |
|---|---|---|
| DB PUT (steady) | 14.75M ops/sec | 70 ns |
| DB GET (steady) | 10.71M ops/sec | 90 ns |
| DB GET (steady, TTL mixed) | 17.47M ops/sec | 50 ns |
Sharded GET, 16 threads: 203M ops/sec (no contention) / 281M ops/sec (hotspot)
The hotspot number scales super-linearly because multiple readers traverse the
same cached ART path simultaneously without contention.
Reproduce with zig build bench -Doptimize=ReleaseFast.
No network layer or RESP interface, by design. The goal is a clean embeddable primitive, so things can be build on top of it.
To show what that looks like in practice, I also built zeno-shell (GitHub - zeno-core/zeno-shell · GitHub), a shell history autocomplete tool for bash/zsh that uses Zeno as its storage backend. It records every command with frequency and recency metadata, and ranks suggestions with a decay score. Small project, works well in a few specific cases, not so well on others, but it was just an exercise to see how it would be to use the engine as a dependency.
External documentation is still a work in progress, currently setting up github pages to cover the architecture and API in more detail.
Happy to discuss any part of the internals and would appreciate any feedback.