The latency figure that you’re looking at comes from within the FDB client library itself. Using .wait() to block on the get(key) future is the expected thing to do, and would occur in your bindings wrapping the client library, and thus wouldn’t affect the client library’s perceived latency. This is why I’m suspicious that you’ve either accidentally fallen into an FDB benchmarking anti-pattern in your client code (of saturating the networking thread), or that there’s something horrible happening within your FDB cluster (like a recovery happening every 5s).