Que vs Sidekiq vs delayed_job

Overview

Sidekiq

Stacks1.2K

Followers632

Votes408

delayed_job

Stacks53

Followers65

Votes6

GitHub Stars4.8K

Forks952

Que

Stacks16

Followers20

Votes0

Que vs Sidekiq vs delayed_job: What are the differences?

Introduction: When working with background job processing in Ruby on Rails, developers have several options to choose from, including Que, Sidekiq, and delayed_job. Each of these tools has its own set of features and capabilities, making it important to understand the key differences between them in order to choose the best one for a specific project.

1. Scalability and Performance: Sidekiq is known for its high scalability and performance due to its use of multithreading, while Que and delayed_job rely on single-threaded processing. This allows Sidekiq to handle a larger number of concurrent jobs more efficiently, making it a preferred choice for applications with high volumes of background jobs.

2. Redis Dependency: Both Sidekiq and delayed_job require Redis as a backend for job processing, while Que utilizes PostgreSQL's advisory locks for queuing jobs. This difference in dependencies can impact the overall architecture and setup of the application, with Que offering a more seamless integration for projects already utilizing PostgreSQL.

3. Active Development and Maintenance: Sidekiq has a strong community and active development, with frequent updates and improvements being released regularly. On the other hand, delayed_job has seen slower development in recent years, which may affect its compatibility with newer versions of Ruby on Rails and potential security vulnerabilities. Que falls somewhere in between, offering steady development but with a smaller community compared to Sidekiq.

4. Error Handling and Retries: Sidekiq provides robust error handling and retry mechanisms out of the box, allowing developers to easily configure policies for retrying failed jobs. This feature is essential for ensuring the reliability of background job processing. Que and delayed_job also offer similar functionalities but may require additional configuration and customization to achieve the same level of reliability as Sidekiq.

5. Cost and Licensing: Sidekiq is a commercial product with a freemium model, offering additional features and support through paid licenses. On the other hand, Que and delayed_job are open-source and free to use, making them more cost-effective options for projects with budget constraints. The choice between these options may depend on the project's requirements for support and additional features provided by commercial offerings.

6. Ease of Setup and Configuration: Sidekiq is known for its ease of setup and configuration, with clear documentation and a straightforward installation process. Que and delayed_job also offer simple setup procedures, but may require more manual configuration and tuning for optimal performance compared to Sidekiq. Developers looking for a quick and easy implementation may find Sidekiq to be the most user-friendly option among the three.

In Summary, understanding the key differences between Que, Sidekiq, and delayed_job is crucial for selecting the right background job processing tool based on specific project requirements and constraints.

Share your Stack

Help developers discover the tools you use. Get visibility for your team's tech choices and contribute to the community's knowledge.

View Docs

CLI (Node.js)

Manual

Detailed Comparison

Sidekiq	delayed_job	Que
Sidekiq uses threads to handle many jobs at the same time in the same process. It does not require Rails but will integrate tightly with Rails 3/4 to make background processing dead simple.	Delayed_job (or DJ) encapsulates the common pattern of asynchronously executing longer tasks in the background. It is a direct extraction from Shopify where the job table is responsible for a multitude of core tasks.	Que is a high-performance alternative to DelayedJob or QueueClassic that improves the reliability of your application by protecting your jobs with the same ACID guarantees as the rest of your data.
-	-	Concurrency; Efficiency; Safety;Transactional Control;Atomic Backups;Fewer Dependencies; Security
Statistics
GitHub Stars -	GitHub Stars 4.8K	GitHub Stars -
GitHub Forks -	GitHub Forks 952	GitHub Forks -
Stacks 1.2K	Stacks 53	Stacks 16
Followers 632	Followers 65	Followers 20
Votes 408	Votes 6	Votes 0
Pros & Cons
Pros 124 Simple 99 Efficient background processing 60 Scalability 37 Better then resque 26 Great documentation	Pros 3 Easy to get started 2 Reliable 1 Doesn't require Redis	No community feedback yet

What are some alternatives to Sidekiq, delayed_job, Que?

Beanstalkd

Beanstalks's interface is generic, but was originally designed for reducing the latency of page views in high-volume web applications by running time-consuming tasks asynchronously.

Hangfire

It is an open-source framework that helps you to create, process and manage your background jobs, i.e. operations you don't want to put in your request processing pipeline. It supports all kind of background tasks – short-running and long-running, CPU intensive and I/O intensive, one shot and recurrent.

Resque

Background jobs can be any Ruby class or module that responds to perform. Your existing classes can easily be converted to background jobs or you can create new classes specifically to do work. Or, you can do both.

Faktory

Redis -> Sidekiq == Faktory -> Faktory. Faktory is a server daemon which provides a simple API to produce and consume background jobs. Jobs are a small JSON hash with a few mandatory keys.

Kue

Kue is a feature rich priority job queue for node.js backed by redis. A key feature of Kue is its clean user-interface for viewing and managing queued, active, failed, and completed jobs.

Bull

The fastest, most reliable, Redis-based queue for Node. Carefully written for rock solid stability and atomicity.

Cron

Background-only application which launches and runs other applications, or opens documents, at specified dates and times.

PHP-FPM

It is an alternative PHP FastCGI implementation with some additional features useful for sites of any size, especially busier sites. It includes Adaptive process spawning, Advanced process management with graceful stop/start, Emergency restart in case of accidental opcode cache destruction etc.

Goose

It is a simple, reliable & scalable background processing library for Clojure. It has a transparent design & cloud-native architecture.

runit

It is a cross-platform Unix init scheme with service supervision, a replacement for sysvinit, and other init schemes. It runs on GNU/Linux, *BSD, MacOSX, Solaris, and can easily be adapted to other Unix operating systems.