GoodJob author here.

The core reason I wrote it was to see how lean/simple I could write a database-backed ActiveJob adapter today. And hope

In practice any adapter should _just work_, but also all the other adapters pre-date ActiveJob (Rails 4.2) and Concurrent::Ruby (adopted in Rails 5.0 I think). The assumption is that building GoodJob on top of what already exists in Rails today, it can be performant (enough) and simple (easy to understand, maintain, keep compatible with new versions of Rails, etc). That's not a big claim, but maybe it's compelling.

Awesome! Thank you so much for the reasoning behind it. I haven't had a chance to look at Concurrent::Ruby but that _sounds_ like a pretty good reason all by itself!

As a big plus for a lot of folks who don't need absurd throughput, this makes for one less dependency by using the same db you already have. I'd be sold given the right use-case, thanks for sharing this, mate and _good job!_ ;)

Yay!

I believe Resque was fork based (at least initially, it may have changed, I haven't looked at it in a while!), while GoodJob appears to be multithreaded (like Sidekiq), so this is quite different in terms of performance & throughput.

I didn't look into this one yet besides the home page, but I always thought Postgres would make a killer backend for ActiveJob, leveraging advisory locks for synchronizing jobs and such. Resque is Redis backed, but if you don't want to add that as a dependency and already have Postgres setup, then this would be a great fit.

Because of the MVCC implementation (needing VACUUM) it's not ideal without tuning.

You can implement background processing with less operational complexity. This allows you to leverage activejob to get something up and running quickly and easily.

Granted, if you start having higher throughput, you want to move on from using postgres as your message bus.