Methodology

A useful comparison shows its limits.

This guide is a decision aid, not a league table. The source revision, adapter scope and model assumptions are part of each claim.

Three evidence types

Documented semantics come from current primary documentation or inspected source snapshots. Each profile pins its inspected source revision, names the release separately, and retains qualifiers. A version label is not a promise that every page on a moving documentation site describes that release.

Measured evidence requires an actual run with a pinned environment, adapter and workload. This site has no current comparative results and does not recycle old point-in-time figures as product rankings. The eight repository adapters are labelled as coverage only.

Pedagogical simulation is the Awa failure lab. Its deterministic events explain a mechanism. They do not measure recovery time, demonstrate a production incident or prove metastability.

Coverage is selected, not exhaustive.

We cover the 8 job-system adapters present in this repository, then add six relevant ecosystem entries, including PotatoQ. Original PgQ is distinct from NikolayS’s pgque. Solid Queue is a multi-database Rails backend; PotatoQ is a multi-broker worker. Their PostgreSQL paths are the scope here.

Adjacent systems such as DBOS, JobRunr, Hangfire and TaskIQ PostgreSQL integrations are not reviewed in this edition. Redis-only workers, Kafka brokers, CDC pipelines and general PostgreSQL databases are outside this guide’s job/queue scope. Absence is not a statement of quality or support.

Language/SDK labels do not imply equal maturity, parity or identical database support. Inspect each project’s PostgreSQL driver and the cited version before choosing an integration.

What a useful measurement must retain

Start from a workload and a contract: handler work, payload, producer behavior, concurrency, batch size, pool budget, database/image and host allocation. Keep warmup separate from measurement and include backlog, latency, completed work, storage churn and recovery. A high enqueue rate alone does not establish end-to-end capacity.

Repeat the run under stable conditions. Sampling one execution over time is not independent replication. Missing observations, aborted runs and unexpected duplicates are evidence to retain and explain, not zeros to fill in or cells to discard silently.

Adapter initialization, claim/ack granularity, driver behavior, reconnect and shutdown all matter. Read and test the public API integration before interpreting a result as a product property. Different contracts remain different even on the same database.

No new benchmark was run for this guide. The website omits old snapshot reports and numerical leaderboards. Existing repository evidence/history has been preserved, without presenting those old versions as current behavior.

Read the measurement plan and adapter coverage →

Three boundaries that are easy to conflate

Enqueue atomicity

Joining the same database transaction can make the business change and new work commit together. An after-commit hook can avoid work before commit, but does not itself close the crash gap after the business transaction commits.

Claim ownership

A lock, lease or receipt helps workers coordinate. Crash recovery depends on the actual mechanism and timeout. Some frameworks record abandoned work as failed rather than automatically requeueing it; those differences appear in profiles.

External side effects

At-least-once recovery can repeat execution. Even a strong database-side guard does not roll back an email or make an unrelated payment atomic. Uniqueness at enqueue is also different from provider idempotency. Follow the system’s actual documented contract and design external effects around it.

How this stays reviewable

The source lives in website/ in the benchmark repository. The catalogue is data, page generation is dependency-free Node.js, and browser behavior is plain JavaScript. There is no analytics, tracking, backend, live database or third-party runtime request.

New systems need a canonical upstream, an explicit source snapshot, source-backed capability entries, tradeoffs, and a coverage label. New measurements need their own run context and evidence review; never mix incompatible environments into one ranking. Unknowns are an acceptable result.

Conflict of interest: the repository is owned by Awa’s author. Profiles are alphabetical, all systems use the same evidence fields, and no numerical feature score is assigned. Corrections should cite upstream docs/source and the affected revision.

Browse every primary source →