It very much isn't. Most well crafted Rails apps try to minimize IOs inside web requests by deferring any long IO into background job, and trying to optimize SQ

It very much isn't. Most well crafted Rails apps try to minimize IOs inside web requests by deferring any long IO into background job, and trying to optimize SQL queries. At best you may find apps that are 50% IOs. That may seems like a lot, but since you can only execute one fiber (or thread) at a time (because there is a GVL), that means two concurrent requests per process. So in such scenario there isn't a lot of benefit in making fibers your main execution primitive (each request get one fiber). You'll save a handful of MB of RAM, but loose thread preemption, meaning your latency will frequently be impacted. Doesn't mean fibers are useless though. You can still have a mix of forking and threads, and then use fibers inside your request cycle to query resources concurrently. But fiber based servers are not really well suited for hosting Rails apps. They're much more suited for extremely IO heavy tasks, like proxies or bridge. e.g you subscribe to Redis and forward events into a websocket, that sort of things.