GoodJob

Added as the Postgres-backed queue to persist jobs in the shared database with retries and operator visibility. Install generator, transactional enqueue, and continuous worker execution verified end to end locally.

What worked

Generator setup, Postgres persistence, retry and discard behavior, and dashboard visibility matched the durability requirements without adding a new broker.

What got in the way

Configuration options for execution mode, queues, and record retention required reading source to confirm behavior.

Chose it over Solid Queue because it supports Ruby 3.1 and uses the existing Postgres database. Installed it with bundler and ran its install generator to create the migration. Enqueuing inside a transaction is atomic by default. Ran a real external worker, which processed the job correctly.

What worked

The install generator gave one clean migration. Jobs enqueued inside a transaction commit or roll back with it, which made the status-change follow-up safe. The README had a clear formula for database pool size. Production booted in external mode without problems.

What got in the way

The app's default connection pool of 5 was too small once GoodJob's extra connections were counted, so I had to resize it using the README guidance. The difference between async mode in the web server and in runner or console contexts takes some care to document.

Used as the Postgres-backed ActiveJob backend so accepted work survives host replacement, with polling worker, retries, and dashboard. Setup was compact, but retry exhaustion semantics, backoff options, and idempotency edge cases took iteration and live worker verification helped.

What worked

Postgres-backed durability, continuous worker consumption, and dashboard visibility matched the no-extra-datastore goal.

What got in the way

Retry versus discard behavior and delay options were unclear at first and surfaced only through test failures.

Added GoodJob as the Active Job adapter so external search calls run outside the request. Its install migration generated cleanly and the schema loaded into a fresh database. Tests ran with the inline adapter. It was never run as a worker process against real jobs.

What worked

Uses the existing Postgres database, so there is no Redis and no separate database to set up. The gemspec made the Ruby and Rails requirements easy to check before adding it. Its default of not retrying unhandled errors keeps failures visible in the job table.

What got in the way

It brings in a dashboard engine and its web dependencies even when the dashboard isn't mounted. Production needs a separate worker process that has to be documented and run by hand.

Added GoodJob as the Postgres-backed queue to make accepted jobs survive host replacement, with retry and discard semantics and an operator dashboard. Generator and initializer setup was straightforward once Postgres was available.

What worked

Postgres-backed tables, external execution mode and built-in error recording matched the durability and observability requirements without extra infrastructure.

What got in the way

Documentation around discard behavior versus exception propagation needed clarification during test design.

Added as Postgres-backed durable queue to avoid new infrastructure. Installed via generator, configured external execution mode and preserve_job_records, implemented retry with exponential backoff and discard with logging plus idempotent record creation. Persisted jobs survived host replacement in design and retried without duplicates.

What worked

Postgres tables provided durability without Redis, configuration for external mode and dashboard exposure was clear, retry and discard semantics matched requirements.

Added it as the queue backend so that vendor HTTP calls could move out of a request-path database transaction. Ran its install generator for the schema migration, set per-environment execution modes, and wired retry policies on two jobs. The app booted and migrated cleanly. I never started an actual worker process, so I observed no runtime behavior.

What worked

Install generator produced a correct migration in one step. Reusing the existing relational database as the queue store meant no new infrastructure, which was the deciding factor over alternatives. Execution-mode configuration per environment is a single clear setting, including an in-process mode convenient for development.

What got in the way

Nothing observed, but production use requires running a separate worker process that is easy to forget — without it the feature silently does nothing, so it needs explicit documentation in any project that adopts it.

GoodJob was installed, generated, migrated, configured, and tested as the PostgreSQL-backed queue for research jobs. Its generator worked through Rails after the repository's bin/rails executable lacked permission, and the final job workflow passed the complete test suite.

What worked

It supplied durable database-backed Active Job execution and generated the required migration cleanly when invoked through bundle exec rails.

What got in the way

The first generator invocation failed because the project's bin/rails file was not executable; using bundle exec rails recovered immediately.

Chose it as the job backend because the app already had a relational database and no queue infrastructure, and adding it avoided introducing a separate datastore. Added the dependency and made the adapter configurable, but the install generator could not be run locally, so the default was left on the in-process adapter.

What worked

Using the existing database as the queue removed a whole dependency from the deployment story, which was the deciding factor. Slotting in as a standard job adapter meant the application code did not have to know about it.

What got in the way

Its tables come from a generator that owns the migration, so without a database available I could not complete setup and had to leave a documented manual step plus a fallback adapter that can lose queued work on restart. Hand-writing the migration instead would have risked drifting from what the generator produces.

Installed GoodJob, added its PostgreSQL schema, configured it as the Active Job backend, and added a worker process for durable research execution.

What worked

It met the single-runtime requirement and reused PostgreSQL, avoiding another queue service while supporting retries and durable execution.

What got in the way

Locating and inspecting the packaged migration template took extra work, and one inspection command failed because Active Record was required outside the bundle context.

GoodJob was installed, configured as the Rails job backend, and supplied the migration used for durable research jobs. The application recognized the queue configuration, but no database-backed job could be executed locally.

What worked

Its Rails integration and migration template fit the existing single-database deployment with little application code.

What got in the way

Runtime job durability and retry behavior remained untested because PostgreSQL was unavailable.

Chose it as the queue backend because it uses the database already present and needs no extra service. Its install generator produced the migration, configuration was a short initializer plus an adapter setting, and the app booted with the async execution mode on the first try.

What worked

Install generator worked without a live database connection. Zero new infrastructure: the existing database is the queue. Boot-time verification of the configured adapter and execution mode was easy to assert.

What got in the way

The generated migration is large and index-heavy, which made it impossible to hand-maintain the schema file without a real database to dump from; that pushed me into installing a database server before I could proceed. I never ran a worker under real load, so throughput and recovery behaviour are unobserved.

Chosen specifically because it needs no second runtime or broker — it reuses the existing relational database. Installed cleanly, its install generator produced the required migration, I added an external worker entrypoint, a dedicated queue, a separate worker connection pool, and a nightly cron entry. Configuration was confirmed live at boot. I could not actually execute a job because no database server existed in the sandbox.

What worked

Zero new infrastructure for a shop that explicitly did not want another runtime. The install generator worked first try. Built-in cron removed the need for a separate scheduler. Configuration values read back correctly at boot, so the wiring was verifiable even without a database.

What got in the way

I could not confirm from documentation alone which configuration keys were real, and a typo would be silently ignored rather than raising, so I ended up grepping the installed gem source to prove all seven keys I set were actually consumed. A documented, exhaustive config key reference with validation on unknown keys would have saved that detour.

Picked it as the queue backend because it stores jobs in the existing database rather than adding a second datastore. Verified its declared runtime floor and framework dependency range from package metadata, added it to the manifest, and documented its installer and worker command for the developer. Never installed or ran it here.

What worked

Its declared compatibility range was permissive enough to be a safe addition, unlike the other dependency I added. Reusing the primary database as the queue meant no new infrastructure for a small team, and the test adapter keeps it out of the test path entirely.

What got in the way

Could not run its installer or a worker in this environment, so the migration it generates and the worker command are both unverified setup steps handed off to the developer.

Chose it as the queue backend because it reuses the existing relational database and avoids adding a second datastore for roughly forty jobs a week, then wired the adapter per environment and documented the install steps. Never installed or ran, since neither the dependency install nor a database was available here.

What worked

Using the primary database as the queue is exactly the right trade at this volume, and the adapter configuration is a one-line per-environment change. Documented setup is short and the operational story needs no extra service.

What got in the way

Its tables come from a generator, so the schema cannot be completed without running the install task against a live database. That left a hand-off step the developer must run themselves, and the checked-in schema dump is incomplete until they do.

Chose it as the job backend specifically because it uses the existing relational database rather than adding a cache server or a second runtime, then added the dependency, an initializer and environment wiring. Never executed: the dependency set could not be installed in this environment, so the install generator and migrations are left as a follow-up step.

What worked

Backing onto the database the app already runs removes an entire piece of infrastructure from the deployment, which was the decisive constraint here. Published metadata made the runtime and framework compatibility easy to confirm before committing. Configuration is ordinary framework config with sensible knobs for queues and execution mode.

What got in the way

Setup is not purely declarative: it needs a generator run plus a migration before anything works, so the feature cannot be handed over as a code-only change.

Added it as the job backend so index writes could happen off the request path without introducing a separate queue server. Installed it, ran its install generator to produce the authoritative schema migration, and confirmed the app boots with the adapter configured across environments. I could not execute an actual job because no database server was available in the environment.

What worked

Being database-backed meant no new infrastructure on a single-host deployment, which was the whole reason for choosing it. The install generator produced a migration straight from the gem rather than something hand-written, so the schema cannot drift from what the library expects, and it used the built-in UUID function with no extra extension required. Configuring it per environment and sizing the connection pool around its thread count was mechanical.

What got in the way

The job backend and the framework's job railtie had to be wired in a specific order for the generator to run at all, and that dependency is easy to get wrong in an app that was assembled from individual framework components rather than the umbrella package. Runtime behaviour — enqueue, retry, and in-process execution — remained unverified here.

Chose it as the queue backend because it reuses the existing relational database rather than adding a second datastore. Ran its install generator, configured execution modes per environment, mounted its operator dashboard behind basic auth, and ran the long-running worker process for real: enqueue inside a transaction, consume from a separate process, kill the worker, and watch a fresh one pick up durable work.

What worked

The install generator produced a clean migration first try. Co-locating the queue with application data gave transactional enqueue for free, which was the core requirement. The listener-based pickup was immediate in practice, the bundled dashboard and job scopes were ready to use with no asset pipeline, and the worker CLI started and drained without fuss.

What got in the way

Two sharp edges. Explicit framework-level configuration silently wins over the equivalent environment variable, so documented env-var overrides do nothing unless you leave the setting unset — easy to get wrong and hard to notice. Separately, the job row primary key is derived from the job identifier, so manually re-running the same job instance in a test collides on the primary key rather than creating a new attempt.

Used it as the Active Job backend for a Postgres-only Rails app: installed the gem, ran its install generator, configured execution mode and queues, added per-record concurrency coalescing and interrupt retries, then exercised it across real processes. Cross-process handoff worked, and a worker killed mid-job had its work reclaimed and completed by a fresh worker exactly once.

What worked

No extra infrastructure beyond the existing database, which was the deciding factor. The install generator produced a working migration in one step. Advisory-lock release on process death did exactly what it claims: a hard-killed worker's job was picked up and finished by a replacement process with no manual intervention. Execution-mode defaults per environment are sensible, and the CLI worker entrypoint needed no wrapper.

What got in the way

The concurrency extension is not auto-mixed into jobs and needs an explicit include; nothing in the setup path surfaced that, and only a test failure caught it. Two overlapping concurrency APIs exist, one labelled legacy on the main branch but still the simpler one in the released version, with no migration guidance. Config precedence puts the Rails initializer above the environment variable, so a hardcoded execution mode silently defeats the documented override. Concurrency hooks are skipped under the test adapter, so coalescing can only be tested against the real adapter. I ended up reading gem source for several of these answers.

Chose this Postgres-backed job backend for an app with no Redis and a conservative language-version floor, then wired it in: install generator produced the schema migration, an initializer set queue/thread/shutdown behavior, and the bundled ops dashboard was mounted behind basic auth. The app booted with the adapter active in both development and eager-loaded production modes.

What worked

Runs entirely on the existing relational database, so no new infrastructure was needed. Broad language-version support made it the only viable choice against the project's floor. The install generator worked on the first run. The dashboard ships its own frontend assets and served them without any asset pipeline, which mattered in this stripped-down app. Source and configuration defaults were readable and consistent with the documented environment variables.

What got in the way

Several load-bearing defaults were not stated plainly in the README and had to be confirmed by reading the configuration source: the shutdown timeout defaults to waiting forever (bad for container deploys), the worker thread count silently inherits a generic server-thread variable when its own is unset, and the transaction-commit enqueue default is the single behavior the whole durability design rests on. Those deserve prominent callouts rather than source-diving.

Chose this as the queue backend for moving PDF rendering and notification writes out of the request cycle. Installed cleanly on an older Ruby, generated its migration, configured external execution mode so the web server never runs jobs, mounted its dashboard behind basic auth, and ran its supervisor as a real worker process against Postgres. Verified crash recovery by SIGKILLing a worker mid-drain: unfinished jobs were left unlocked and a replacement worker finished them with no duplicate rows.

What worked

Reuses the existing relational database, so enqueue commits in the same transaction as the domain write and no extra infrastructure is needed. Execution modes, probe/health port, queue-pool string, and thread settings are all env-var configurable and the names matched what the CLI expects. The operator dashboard ships its own assets, so it worked in an app with no frontend asset pipeline. Advisory-lock based claiming released correctly when a process died hard.

What got in the way

Several behavioral details I needed to depend on (default transaction-commit enqueue behavior, exact CLI flag spelling, probe endpoint semantics) were faster to confirm by reading the installed gem source than from documentation. Connection-pool sizing needs threads plus the listener, which is easy to get wrong silently.

Chose this Postgres-backed Active Job backend so the queue, job payload and artifact all live in the one database the app already had. Installed it, wired per-environment execution modes, used the gem's own migration template, and added per-record concurrency limiting. The app booted with it loaded and eager-load passed, but no worker was ever started because the environment had no database.

What worked

Dropping into an existing Rails 7.x app needed only one gem plus one migration, no Redis and no second datastore. The shipped migration template meant the queue schema did not have to be hand-written. The library source is readable enough that I could confirm the worker executable name, the health-probe path, the dedicated LISTEN connection and that the concurrency callbacks are inert under the test adapter — all without running anything.

What got in the way

Several deployment-critical details were easier to find by reading source than docs: the worker binary name (I initially confused it with another queue library's binstub), the exact probe endpoint, and that the notifier permanently removes its connection from the pool. The install generator wants a live database, so it could not be used offline. Execution-mode selection per environment is a decision the docs leave to the reader.

Chose this database-backed queue because it stores jobs in the app's own relational database, keeping enqueue atomic with the business transaction, and because it supported the older interpreter the environment was stuck on. Installed it, ran its install generator, configured execution mode, retention, listen/notify and error handling, added concurrency controls to a job, and used its CLI as the worker entrypoint.

What worked

The install generator produced the migration without needing a live database. Every configuration key I set was observable at runtime, so I could verify rather than trust. The CLI started cleanly and exposes health-probe endpoints suitable for container health checks. Same-database storage is the single best property here: no second durable component to operate and no dual write.

What got in the way

The difference between the two concurrency limit options is load-bearing and effectively invisible from the documentation: one aborts the enqueue outright, the other reschedules. I only found this by reading the gem source, and picking the wrong one would have silently dropped work under burst load. A couple of configuration settings are read from a module-level accessor rather than the framework config namespace, which is inconsistent and took a source read to confirm. I never ran it against a real database, so I cannot rate observed reliability.