Writing ·
Hangfire vs Sidekiq: .NET vs Rails Background Jobs
By Sovaid Shah, Software Architect · Hangfire · Sidekiq · .NET · Rails · Background jobs · Architecture
TL;DR: Pick by stack first: Hangfire for ASP.NET Core, Sidekiq for Rails. Hangfire stores jobs in your database (SQL Server by default), so it is durable and easy to inspect but slower under heavy load. Sidekiq runs on Redis with threads, so it is very fast, but free Sidekiq can lose an in-progress job if a process dies; Sidekiq Pro fixes that. Both give you retries, scheduling and a dashboard.
I’ve run background jobs in production with both tools. Hangfire powers job scheduling on ATC, an enterprise HR and project management hub built on ASP.NET Core and Vue. Sidekiq ran alerting and scheduled work on Go Green Together, a Rails 6 energy management platform with live dashboards.
People ask “which is better?” That’s the wrong question, because you almost never get to choose freely. The right question is: what does each one assume, and what breaks when that assumption is wrong?
The short answer
| Hangfire | Sidekiq | |
|---|---|---|
| Language | .NET (C#) | Ruby |
| Job storage | Your database (SQL Server by default; other storages available) | Redis |
| Execution model | Worker threads polling storage | Threads pulling from Redis queues |
| Default retries | 10 attempts | 25 attempts with exponential backoff (about 21 days) |
| Recurring jobs | Built in (RecurringJob.AddOrUpdate with cron) |
Sidekiq Enterprise, or gems like sidekiq-cron |
| Dashboard | Built in | Built in (Sidekiq::Web) |
| Paid tier adds | Batches, Redis storage (Hangfire Pro) | Reliable fetch, batches (Pro); periodic jobs, unique jobs (Enterprise) |
Where Hangfire wins
Durability without new infrastructure. Hangfire writes job state to the same SQL Server your app already uses. There’s no Redis to run, back up and monitor. For an enterprise hub like ATC, where ops teams already know how to run SQL Server, that matters more than raw speed.
Everything is inspectable. Every enqueued, scheduled, failed and succeeded job sits in tables you can query. The dashboard shows the same thing. When someone asks “did last night’s sync run?”, you can answer in seconds.
Scheduling is first-class. Fire-and-forget (BackgroundJob.Enqueue), delayed (BackgroundJob.Schedule), recurring with cron (RecurringJob.AddOrUpdate) and continuations (ContinueJobWith) all ship in the free version.
The cost: database-backed queues are slower than Redis and add load to your primary database. At high volume, give Hangfire its own database or schema, and keep an eye on the polling.
Where Sidekiq wins
Throughput. Sidekiq runs many jobs concurrently in threads on one process, and Redis queue operations are fast. For high volumes of short jobs like alerts, emails and webhook fan-out, it’s hard to beat. On Go Green Together, Sidekiq-backed alerting fed ActionCable dashboards that needed to update while the data still mattered.
The Rails ecosystem. It plugs into ActiveJob, and most Rails developers already know it.
The cost: free Sidekiq fetches jobs with a blocking pop from Redis. If a process is killed mid-job, that job can be lost. Sidekiq Pro’s reliable fetch fixes this. For anything involving money or user-visible state, either pay for Pro or make your jobs safe to re-run and reconcile them separately.
The rules I follow with either tool
These matter more than which library you pick:
- Make every job idempotent. Retries are a feature. A job that charges a card or sends an email must be safe to run twice.
- Pass IDs, not objects. Enqueue
user_id, then load fresh data inside the job. Serialized objects go stale, and Sidekiq arguments must be simple JSON anyway. - Keep long work off the request path. That was the whole point on ATC: HR and project workflows spike, and batch work must not slow the API users are waiting on.
- Separate queues by urgency. Critical, default and bulk queues stop a nightly import from delaying password-reset emails.
- Alert on the dead set and on queue latency, not only on errors. A queue that’s growing quietly is the outage you’ll find out about too late.
Which should you choose?
- ASP.NET Core app: Hangfire. Look at alternatives (Quartz.NET for pure scheduling, a message broker for event-driven systems) only if you have a specific reason.
- Rails app: Sidekiq. Rails 8 also ships Solid Queue, which is database-backed and fits teams that want to avoid Redis.
- Mixed estate: use each in its own stack. Don’t force one language’s job system on the other. If the two stacks need to share work, use a message broker between them.
FAQ
Is Hangfire the .NET equivalent of Sidekiq?
Roughly, yes. Both are background job processors with retries, scheduling and a dashboard. The main difference is storage: Hangfire defaults to your database, Sidekiq requires Redis.
Can Sidekiq lose jobs?
Free Sidekiq can lose a job that’s in progress if the process crashes or gets killed. Sidekiq Pro’s reliable fetch prevents this. Idempotent jobs plus reconciliation limit the damage either way.
Does Hangfire need Redis?
No. Hangfire works with SQL Server out of the box. Redis storage is available through Hangfire Pro or community packages, if you need more throughput.
See how this played out in production in the ATC case study and the Go Green Together case study. Planning job architecture for your system? See software architecture.