lsm-tree storage engine · c++20 · zero-dependency core · booting engine…

strata.

In a storage engine the interesting property is not speed, it's the contract: an acknowledged write exists after any crash, and recovery never invents data. The engine below is the real library, WAL, memtables, SSTables, group commit, compaction, compiled to WebAssembly, wearing the same byte-exact crash gate its test suite uses. Cut its power and see.

github.com/lgoyal6/strata skip to the crash ↓
11,149real SIGKILLs mid-write in the crash matrix; zero acknowledged writes lost
50×RocksDB on synchronous commits: group commit shares one F_FULLFSYNC across writers
0.4×scans, where RocksDB wins; the losing axes are published too

12 configs × 1,000 kills on every CI push · bench/results/crash_matrix.txt · raw YCSB CSVs in the repo

01

Break it

write real records, arm a power cut a few hundred KB ahead, and reboot into recovery
0 records acknowledged · 0 bytes through the WAL

Fig. 1. What's on disk, live: the write-ahead log accretes at the top, memtable flushes harden into L0 tables, compaction fuses them into the leveled strata below. The power cut arms the same fault-injection gate as tools/crash_test, a byte offset inside the engine's own write path; everything acknowledged before the tear must survive the reboot, with every value byte-identical. The browser filesystem is in-memory: the durability mechanics (WAL bytes, torn-tail truncation, replay) are real, but throughput here is not a disk number; the measured numbers above come from real hardware, see docs/BENCHMARKS.md.

02

Poke it

your own keys land in the same memtable; the counters are the engine's own 
// keys and values land in the real memtable; puts are acknowledged after the WAL write

Fig. 2. Every put is a WAL record and a skiplist insert; every get walks memtables, then the levels, bloom filters first. Delete writes a tombstone that survives until compaction drops it at the bottommost level.

Table 1. Live engine counters.
write amplification–
flushes0
compactions0
write stalls0ms
bloom skips–
block-cache hits–

Backpressure is visible here: pile up L0 files without compacting and the engine stalls writes rather than OOM.

03

What you just saw

every behavior above is a specific piece of the engine
THE GATE
A power cut landing at an exact byte inside a write.
Fault injection at the engine's single write choke point, the same gate tools/crash_test uses to SIGKILL 12,000 runs on CI. The kill offset is a byte count, so torn writes are deterministic and replayable: src/util/env.cc
THE REPLAY
A reboot that recovers every acknowledged record.
WAL replay checks every record's CRC and durably truncates the torn tail it stops at, so a tear can never resurrect on the next crash (a real bug the matrix caught): src/wal/wal_reader.cc, src/wal/wal_writer.cc
THE TREE
Files hardening, sinking, and fusing into levels.
Skiplist memtables flush to prefix-compressed SSTables with bloom filters; size-tiered L0 merges into leveled L1…L6 with snapshot-aware GC: src/db/memtable.cc, src/table/table_builder.cc, src/db/version.cc
THE CONTRACT
Nothing invented, nothing lost, in any order.
Every byte on disk is CRC-guarded or reconstructible; the manifest recovers by full snapshot, atomic rename, directory fsync; group commit batches writers into one sync: src/db/db_impl.cc, src/util/crc32c.cc