While I agree with your general point (yes a Ruby web app once basic database access patterns have been optimized is essentially CPU/GVL bound), I'd advise caut

While I agree with your general point (yes a Ruby web app once basic database access patterns have been optimized is essentially CPU/GVL bound), I'd advise caution when using things like techempower benchmarks of the benchmark game. Different languages receive very different levels of care in these, and from memory there was some big no-nos in the Rails benchmark. One I remember for instance is that they use redis as a cache but without a connection pool [0], and AFAICT they run puma with at least 5 threads [1], so they are very likely to content on that one Redis connection. That's just one of the many things I spotted when I looked at it a few months back. [0] https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Ruby/rails/config/environments/production.rb#L45 https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... [1] https://github.com/TechEmpower/FrameworkBenchmarks/blob/542904f589b63322b8610b82583ce8fdde97f6d0/frameworks/Ruby/rails/config/puma.rb#L12-L13 https://github.com/TechEmpower/FrameworkBenchmarks/blob/5429... Edit: To add to my point, you linked to the "20 queries" benchmark, which is essentially: render json: 20.times.map { |i| World.find(i) } Somehow this average 260ms latency while the single query version average 8ms, so something definitely don't add up, since worst case scenario it would be 20x slower so ~160ms. Another evidence is that the "cached" version is also 260ms. And this is a dummy app barely doing anything, I've seen apps doing a ton more work in much less time.