&gt; DbOptions::durable()&gt; Appended to the WAL without a per-write syncSo… it’s not durable? Durable doesn’t mean “survives a process restart”, it means “durably saved to persistent storage”. For example, this “durable” mode wouldn’t survive power loss.

I assume this is for hashing. I&#x27;ve seen several hashing algorithms turn to hardware AES instructions before, but I haven&#x27;t seen any evidence that this technique outperforms state-of-the-art hashes like RapidHash (<a href="https:&#x2F;&#x2F;github.com&#x2F;Nicoshev&#x2F;rapidhash" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Nicoshev&#x2F;rapidhash</a>) in either quality or speed.

Iirc that’s how badger handles the WAL as well

Those help but the main write speed gain is the WAL, that uses preallocated mmap segments to avoid a write(2) per durable mutation while preserving crash recovery.
AES hashing mainly helps Bloom filter point lookups and LZ4 mainly helps SSTable I&#x2F;O. Scans benefit indirectly, but don’t yet use a custom SIMD merge loop.

I suppose the insane speed is due to this:&gt; TurboKV&#x27;s persisted Bloom-filter format uses hardware AES.Also, built-in LZ4 compression.I would expect SIMD to be used for scans.