Yeah, I was a little confused by this at first because Heroku also has "workers" which are dynos provisioned to churn through queued background jobs, but unicorn "workers" are totally different: They're processes forked within the web dyno so a single server can process requests concurrently. Each forked process has the entire memory footprint of the Rails app (about 200-250 MB for us), so the more memory you have the more forked processes you can run on a single dyno.

This reduces H12 errors because the more concurrency you have in a single process the less likely it is that Heroku's random routing layer is going to send a request to a dyno that is unable to handle the request because it's busy handling another long running request. As long as long running requests are the exception and not the rule, this should solve the problem.