As long as you stick to pure ActiveJob features it really shouldn't be too difficult to scale from in memory based queue to PostgresSQL backed Good Job and then to Redis backed Sidekiq if and only if you need to.
Yes, I wanted a PG-based one and reached for Good Job on a new project since it was recently created and with Active Job in mind from the start. Check out the intro:
> If a Sidekiq process crashes while processing a job, that job is lost. [0]
We use Sidekiq Pro at work but I find it unfortunate that reliability is a pro feature. It's really hard to tell a product owner: Yeah, we might lose a few jobs once in a while.
I just looked this up. It's $995/year, or approximately 4% of the fully loaded cost of an FTE software engineer at most companies. i.e. about 3 weeks of a developer's time.
However, this recent addition to the space seems to be gaining traction and appears to have an excellent feature set -
https://github.com/bensheldon/good_job