Another aspect is that my tests were run on an old MacBook pro. It is likely that the latencies for the Streams would be even lower on modern hardware and the latest version of C2 compilers. So, in fact, the ratio could be even higher than proposed in the article.

I am interested to learn if you have a reference with sub 15 us latencies for the given requirements. Keep looking!

The new reference you provided is for UDP and not TCP and involves bypassing the kernel whereas the example in the article explicitly involved the kernel. Furthermore the reference was not round trip but just one way.

In the article I talked about nodes at 100 meters distance interconnected via a 10 GBit/s connection and where the CPU is involved in the round trip delay. Your reference is something completely different: it is about a T5 connection at 40 Gbit/s and where there is specialized ASIC involved. All though interesting, it is not relevant to the preconditions presented in the article.

For a 10 Gb/s connection, the time it takes to send a database package of about 1,000 bytes (with approximately 10,000 bits) is about one microsecond one way. There is an additional latency of 300 ns per 100 meter distance. With thread affinity and busy waiting is is possible to come down to about 25 us including context switches, packet handling, content decoding, memory latencies etc.

So, given the prerequisite, the claim stands. However, if you can produce a reference to someone who can do a faster roundtrip delay for database connections on a 10 GBit/s connections, I am eager to learn about it!

This invalidates your claim: "200 ns is more than 125 times faster than the theoretical minimum latency from a remote database (100 m) whose internal processing delay is zero and where a single TCP packet can convey both the query and the response."