// the find
bensheldon/good_job
Multithreaded, Postgres-based, Active Job backend for Ruby on Rails.
GoodJob is a Postgres-native background job processor for Rails that uses ActiveJob's interface, advisory locks for run-once safety, and LISTEN/NOTIFY for low-latency job pickup. It's aimed at Rails teams who are already running Postgres and want to avoid adding Redis to their stack. The sweet spot is apps processing up to a few million jobs per day on standard Rails infrastructure.
Postgres advisory locks for job claiming are the right call — they give you ACID guarantees and automatic lock release if the worker dies, which is exactly where Redis-based queues have historically burned people. LISTEN/NOTIFY for job pickup means latency is measured in milliseconds without constant polling. The concurrency control system (enqueue_limit, perform_limit, throttling) is genuinely useful and baked in, not bolted on. The dashboard is a mountable engine that ships with the gem — no separate deploy, no extra service.
The concurrency control for perform_limit is 'optimistic retry with backoff' — their own docs admit that under high collision rates this degrades badly and you should fall back to controlling concurrency via thread counts instead, which makes the feature feel half-finished for busy queues. PgBouncer in transaction mode breaks advisory locks, so if you're using a connection pooler (most production setups eventually are), you need to route GoodJob connections around it, which is a meaningful ops burden. The v3→v4 priority inversion — higher numbers used to mean higher priority, now lower numbers do — is the kind of silent breaking change that corrupts job ordering in mixed deployments if you're not careful.