Yes, a DBMS may be servicing many requests at once, which is why individual stalls don't matter. Other threads will be making progress. That works if you have

Yes, a DBMS may be servicing many requests at once, which is why individual stalls don't matter. Other threads will be making progress. That works if you have a thread per request. Not all servers are structured this way; thread-per-CPU with non-blocking I/O is increasingly popular. DBMS engineers always make this BS claim and that's what it is, BS. You may know exactly what information you need for a single given query. But you don't know what the next query will be. Let me rephrase that: A database doesn't know which data is most likely to be used again, but if does know which pages are guaranteed to not be used again because they're not reachable in the b+tree. Find any system that gets anywhere close to LMDB's read performance and scalability under heavy concurrent load [...] I would be interested to see how LMDB compares to Kivaloo. In my benchmarking (40 byte keys, 40 byte values, single core on my laptop, highly parallel workload, in core) I get 10^6 reads per second over the network; if I understand correctly LMDB doesn't serve a network protocol but is at a similar level of performance?