I had investigated what explained the huge gap between the few fastest frameworks vs the rest. The answer is a deceptive one, they didn't achieve revolutionary optimizations. The thing is: on many of those benchmarcks, the bottleneck obviously is the DB. The ability to do DB queries asynchronously and with batching is the differentiating factor. Only postrgresql can support such a feature but you need support on the postrgresql client too. The official C postrgresql client used everywhere does not support said feature except with a patch from 2016. Yes the secret of drogon (and probably of Lithium) is that they use a fork of libpq from 2016 because upstream can't agree on merging the patch and nobody is working on upstreaming it. Actix web benefited from the feature because their client tokio-postgres is a reimplementation and does not use libpq.

The industry grade server ecosystem that is the JVM use the jdbc which sadly has a blocking socket thus not allowing asynchronicty. But when loom arrive every jdbc existing code will magically, automatically become truly asynchronous such spring should come on the top 4 place.

There is also a wrapper of the jdbc through kotlin coroutines and there are reactive jdbc implementations such as R2DBC. It is unclear as of today if such solution enable postrgresql async queries and batch processing. It seems that nobody has tried those on TechEmpowerUp which is sad. Finally one could use libpq over JNI. Edit: I have read that the next release of pgjdbc (43) will switch from std socket to the NIO non blocking socket.

What should be heuristically the fastest HTTP framework (H2O, in C) has refused to use the old libpq fork because the api is not stable and thus not production grade.