lsm-tree vs RocksDB

Every engine runs the same workload in one process on one host, in the same rounds: one sample each per round, taking turns at going first, so load on the host slows every engine of a round alike and divides out of their ratio. Relative to RocksDB shows each engine's time over RocksDB's in the same round, the median over all rounds (below 1 is faster than RocksDB); time per operation shows each engine's median. The tooltip gives the 95% confidence interval of either, which covers the noise within a run; two runs of one commit on one host agreed on the ratio to within 2% on the median arm and 7% on nine arms in ten, so a ratio within a few percent of 1 is parity. lsm-tree and RocksDB get the same block size, bloom filter, block cache, values and four block-compression threads, no WAL, and every lsm-tree protection RocksDB has no equivalent for is off; the ours-deferred-wal arm is the exception, writing and syncing a caller-kept log once per batch. SurrealKV, on the uncompressed charts only, runs with its defaults and commits through its own WAL, synced on each commit. · single-engine trend →

No head-to-head results have been published yet.