SolidQueue vs GoodJob Performance Benchmark

Production Results (Jan 2026)

Environment: Ruby 3.4.8 / Rails 8.1.2, SolidQueue 1.3.0, GoodJob 4.13.1, Postgres 16.8, 2 vCPU / 2 GB RAM.

Findings (production runs, 35 per gem): SolidQueue dominates bulk scheduling at larger sizes. Median run times: 10k jobs ~59s vs GoodJob ~120s, 100k ~9.8m vs ~42m, and 1M (single run) ~12.1h vs ~28.2h. GoodJob is faster for one-by-one at small sizes (1k ~24s vs ~36s; 10k ~2.8m vs ~4.0m). At 100k one-by-one, SolidQueue is faster (~1.8h vs ~2.3h). GoodJob's admin UI is notably more complete and feature-rich than MissionControl.

PROs - GoodJob: fastest one-by-one at small sizes; strongest admin UI. CONs - GoodJob: slower bulk throughput and larger tail at 100k+. PROs - SolidQueue: best bulk performance and better large-run scaling; tighter tail. CONs - SolidQueue: slower at small one-by-one sizes; admin UI is less capable.

Recommendation: SolidQueue for production use in this environment (best throughput at scale).

Purpose

This project performs a comprehensive performance benchmark comparing SolidQueue and GoodJob gems on a Rails application.

Quick Start (Local)

This project uses Docker Compose to run PostgreSQL locally. The Rails server runs on port 31500 and PostgreSQL on 31501.

Prerequisites:

• Docker and Docker Compose installed
• Ruby 3.4.8 (managed via mise or your preferred Ruby version manager)
• macOS with Homebrew (for make bootstrap)

make bootstrap  # Install flyctl, overmind, tmux (macOS only)
make db-up
make setup
make dev

Then visit http://localhost:31500.

Current Status

• Production results captured: summarized above.
• Production app paused: the hosted app is currently turned off; re-run as needed later.
• Rails scaffold: PostgreSQL-backed Rails app at repo root, ready for local dev and Fly.io deployment.
• Run tracking + placeholder workload: the UI can create runs and enqueue placeholder work for each adapter. Details: context/technical/benchmark-run-model-and-ui.md.
• Both adapters available: SolidQueue and GoodJob are installed and can be run as separate worker processes.
• Admin UIs available: mounted pages for both queue systems to inspect jobs. Details: context/technical/queue-admin-uis.md.
• Single database setup: all tables (including job tables) live in the primary schema and are prepared via one db:prepare.
• Benchmark harness limited: instrumentation + richer workloads are not implemented yet.

Benchmark Goals

The benchmark aims to answer:

• Which gem performs better under various workload conditions?
• What are the trade-offs between SolidQueue and GoodJob?
• How do they compare in terms of latency, throughput, resource usage, and scalability?
• Which gem is more suitable for different use cases?

Metrics

The canonical metrics list (and how we define them) lives in:

• context/features/benchmark-scope-and-success-metrics.md
• context/technical/benchmark-methodology-and-instrumentation.md

Workloads

The canonical workload axes (and what’s in/out of scope) lives in:

• context/features/benchmark-scope-and-success-metrics.md

Design Docs (Read These First)

This repo is intentionally spec-driven: decisions and detailed design live in context/.

• Scope / questions / success metrics / workloads: context/features/benchmark-scope-and-success-metrics.md
• Methodology + instrumentation approach: context/technical/benchmark-methodology-and-instrumentation.md
• Local dev PostgreSQL (Docker Compose + ports): context/technical/local-development-postgres-docker-compose.md
• Fly.io + Docker strategy (optional): context/technical/flyio-deployment-and-docker-strategy.md
• Reusable agent workflows: context/commands/ (see also context/README.md)

Local Development Notes

Local multi-process dev (web + workers) uses Overmind; see:

• context/technical/local-development-process-management.md

Other useful commands:

• make db-down - Stop PostgreSQL container
• make db-nuke - Stop and remove PostgreSQL container and volume (destructive)
• make db-logs - View PostgreSQL logs
• make psql - Open psql shell in PostgreSQL container

Note: The Makefile uses custom ports (Rails: 31500, Postgres: 31501) to avoid conflicts with other applications. These can be overridden via environment variables if needed.

Deploying to Fly.io

Deploy is optional and primarily exists to make it easy for others to reproduce the environment.

Prerequisites:

• Install flyctl (macOS): make bootstrap or brew install flyctl (see Fly docs: https://fly.io/docs/flyctl/install/)
• Follow the canonical deployment notes in context/technical/flyio-deployment-and-docker-strategy.md

Next Steps

1. Review and refine decision documents in context/
2. Document benchmark scenarios and success criteria
3. Design the benchmark harness and instrumentation
4. Implement benchmark suite and instrumentation