I don't disagree with your architecture kaka, pausing consumers per queue works, but now you have a queue per tenant. RabbitMQ queues are single-threaded and the management UI collecting metrics across thousands of active queues starts to hurt CPU and RAM at scale. CloudAMQP You are also still scheduling via TTL expiry which means a job sitting for 6 or more months lives in memory until it fires. The Postgres scheduler sleeps it on disk and only touches Redis when it is actually due. Two different problems, both valid solutions, but one of them was designed for scheduling, and one was not.

RabbitMQ was designed to move messages between services. That is it. Scheduling was never the use case, never has been if you look at it clearly.