Vapor queue limitations and options. Database queue driver?

Vapor is great - incredible scale and no servers to worry about. However, the queue system is not very flexible. A few issues I have come up against so far:

• Throttle/Funneling - of jobs when you are pushing many thousands to the queue at the same time (not wanting to spend $$$ on a powerful RDS instance). If you run an app with spiked processed (exactly what's Vapor is great for) you can run into issues with RDS performance limitations. If you have an event that triggers a large number of jobs, using Redis funnel/throttle features are good but you may end up releasing your 10,000th job hundreds or even thousands of times before the full run is complete. It is very dirty.

• Prioritising jobs - You may have just pushed 10,000 jobs to the queue but job 10,001 is critical to run within a few minutes. Nothing you can do here but wait.

• Controlling order - We use the Spatie event-sourcing package which requires event reply in exact order. On Horizon you just set up a single worker on a queue and push these jobs to that queue. Your other queues will run as normal but this one queue will still only allow 1 job at a time, which should be in in order. On Vapor, we can set concurrency which applies to the whole environment. We could also use FIFO queues but not out of the box. Again I think this would be for the entire environment too.

What other options do we have? Ideally, a Horizon style system that sits between your app and SQS would be ideal.

Database queue driver - since MySQL 8.0 with skipping locked rows, this is much more performant. I believe we would need to overwrite the "vapor:work" command to get this to work though.