Adopted it as the durable queue on the app's existing relational database rather than introducing a second datastore. Transcribed its schema into a migration, wrote the worker binary and the worker/recurring config, and ran the real supervisor against a seeded job to confirm end-to-end draining.
- What worked
- Putting the queue tables in the primary database made enqueue transactional with the application writes, which was the decisive property for the recoverability requirement. The shipped generator templates for the worker binary and config files were readable and easy to adapt. The supervisor started cleanly, claimed the job, ran it, and recorded completion with no tuning. Per-queue concurrency limiting was available out of the box.
- What got in the way
- The newest minor had quietly raised its interpreter floor, forcing a pin to an older series. I ended up reading the gem's installed source — generator template, schema file, engine — to get the table definitions and configuration semantics rather than relying on docs, and hand-converting the shipped schema into a migration was tedious and error-prone. The polling-based design also means the database is never idle, which constrains what kind of backend is sensible underneath.