No it isn't. LMDB is so lightweight and fast that I don't need async function calls. I can just assume they return virtually instantly.
It makes a lot of sense if you think about it, once the data is paged in, it’s just a btree data structure in memory. Especially if your data is stored as flatbuffers like strfry and nostrdb. In fact, i doubt you can make something faster than lmdb. It’s pretty much optimal cache wise.
I remember when it came out in 2011 or so, people were agahst and in awe of how fast it was.. like this was impossible. And some smart developers went digging to try to find the "problem" because it must be doing something wrong to get that speed. And what they discovered was that it was simply using several really smart techniques in ways people hadn't put together before, like copy-on-write, b+ trees, mmap returning direct pointers to the data instead of copying it, etc. I also think it is probably at or very near the maximum theoretical performance. Of course unlike you, I don't utilize that performance on my relay. wss://chorus.mikedilger.com:444/ is currently only serving 15 connections.
flatbuffers is great, as are binary blobs that are directly accessible without deserialization (such as my pocket-db) or rust `speedy` (barely any deserialization really, but it does still copy). It is funny how copying something actually makes a performance difference for us. That is how fast we are now. For most people a memory copy (with its concomitant malloc) is trivial and lost in the noise of their real performance bottlenecks.