Thanks for the anecdotal counterpoint, that is what I was looking for! I think we're talking about different things though. I think OP was suggesting/question

Thanks for the anecdotal counterpoint, that is what I was looking for! I think we're talking about different things though. I think OP was suggesting/questioning whether a typical Rails apps may spend 90% of it's overall time in I/O. I am suggesting the reverse, that typical Rails apps (so long as they don't have bugs where they fetch more than they need) will spend spend 60-80% of their time in CPU rather than I/O. I am curious if this is true of shoppify's app; my guess is it still would be (especially cause I think shopify will not have very many bugs where it's fetching things inefficiently or that it doesn't need to fetch, shopify will be higher-quality than a random rails app). You are suggesting, I think, that at shopify atypical, problem requests were always due to I/O. I think all of this can be simultaneously true. I think a side issue to what I'm talking about, but: > We spent significant amounts of time finding ways to work around Rail's inability to do these sorts of things in parallel Rails 7 actually recently introduced a feature to do multiple ActiveRecord fetches concurrently... perhaps motivated by/developed by Shopify? https://pawelurbanek.com/rails-load-async https://pawelurbanek.com/rails-load-async I haven't used that one yet. In the past when I've needed to do things like external API requests in parallel, I have had success just using futures/promises from Ruby::Concurrent, without even telling Rails about it. I've had to do this only rarely, but I haven't run into too much trouble. But one thing you can run into if your threads try to store things in ActiveRecord themselves, is running out of database connections with Rails "long connection checkout" model, involving explicit handling of pool checkouts once you do your own threads. Sequel (vs ActiveRecord) has a much more connection-efficient way of pooling database connections, where they are transparently checked out of the pool, under the hood without you usually needing to manage it explicitly, for only as long as it takes to execute a single statement. When doing heavily concurrent things with AR, I have often wished it used Sequel's concurrency/connection-pooling model.