Memory vs LMDB warm cache_hit

How does a warm LMDB answer cache compare to a warm memory cache under sync cache_hit (read-mostly after warm)?

Numbers are same-host comparisons on a single reference host and are not service-level objectives. See the performance hub disclaimer.

When this matters

Use this pair when choosing between an in-process memory cache and a durable LMDB store for a warm, hit-dominated path. Both cells use the same elevated dnsperf window and warm probes before load. This study does not describe fill/evict churn, capacity pressure, or hit-rate under turnover — see Memory vs LMDB high-churn cache.

Configure backends under caches: and lookup profiles. See DNS answer cache and Performance methodology — LMDB cache cells (real disk for publish; lmdb.sync: full).

What we varied

Varied: cache backend (memory vs LMDB) under warmed cache_hit
Held constant: sync runtime, ingress workers, observability off, elevated dnsperf recipe

Evidence

Achieved QPS — sync warm cache_hit (memory vs LMDB)

Download CSV

Cache Backend	Runtime	Achieved QPS	Avg latency (ms)	Sent	Completed	Lost	Workers
memory	sync	329202.8	6.1	3294253	3294253	0	ingress=2
lmdb	sync	311061.7	6.4	3113021	3113021	0	ingress=2

At a glance

sync warm cache_hit (memory vs LMDB): lmdb costs about 6% QPS versus memory (~311k vs ~329k).

Takeaway

Warm LMDB is close to warm memory on this lab. Under the same sync cache_hit recipe, LMDB costs about 6% QPS versus memory (~311k vs ~329k). Treat that as a same-host upper-bound comparison for a read-mostly path after warm — not a capacity target, not a churn or hit-rate claim, and sensitive to disk / page cache. For turnover under pressure, see Memory vs LMDB high-churn cache. See Performance methodology — LMDB cache cells.