In our case, we use queues in ha-mode:all and queue ownership isn't as much of an issue there. Our biggest limiter for some of our workloads is actually message

In our case, we use queues in ha-mode:all and queue ownership isn't as much of an issue there. Our biggest limiter for some of our workloads is actually message size, not velocity. That may change in the future. You're absolutely correct re load balancing for high-performance/ceilings/etc. It's not a huge issue for our use, but I can how it can be for others. In my previous environment, for example, it was absolutely critical. I'm sure this tool isn't for everyone, for us it was about making cluster startup easier and letting RabbitMQ handle that instead of a configuration management system like Chef/etc. For example, our test environment is torn down every night on an autoscaling schedule and rebuilt in the morning. Not having to worry about config management for starting up a new RabbitMQ cluster on demand is a nice feature. :) Thanks for pointing out the clear (and accurate) concerns one must consider when running RabbitMQ @ scale. It sounds your experiences are similar to my own with where the gotchas can be.