From Hangfire to RabbitMQ: Killing Database Polling

Hangfire is great for small teams. You add a NuGet package and point it to your database. You get a job runner and a dashboard for free. For one service, it is hard to beat.

I used Hangfire for SavePosty to handle emails, webhooks, and content fetching. Every job worked the same way. They all polled my Postgres database every few seconds to check for new work.

I eventually moved everything to RabbitMQ. Here is why I did it and what I lost.

Why I moved:

  • Polling load scales with time, not work. Every Hangfire job hits your database on a timer. Even if there is no work, the database stays busy. This cost grows with your job count and poll frequency.
  • Too many models. One part of my app already used RabbitMQ. The rest used Hangfire. This meant two different ways to manage background work. Moving to RabbitMQ unified everything.
  • Latency. A broker pushes work the moment it arrives. Hangfire waits for the next poll.

The trade-offs:

Hangfire is easy to set up. It uses your existing SQL tables. It has a great built-in dashboard.

RabbitMQ requires managing a broker. It uses RAM and network instead of database CPU. You get better scaling, but more operational overhead.

How I migrated safely:

I kept my business logic exactly the same. I built thin consumers that act as a front door. The consumer receives the message and hands it to the existing job class.

I focused on two things:

  • Retry parity. I matched Hangfire retry settings in the RabbitMQ consumer so I did not lose messages.
  • Schema safety. I kept old columns nullable so I did not break the database during the deploy.

What I lost:

The biggest downside is visibility. Hangfire lets you click a failed job and see exactly what happened. RabbitMQ shows you how many messages are in a Dead Letter Queue, but it does not give you that same easy per-job view. I now rely on structured logs instead of a dashboard.

My advice:

Stay on Hangfire if:

  • You run a single service.
  • You have a small team.
  • You need an easy dashboard for debugging.

Move to RabbitMQ if:

  • You have multiple services.
  • Your database load from polling is high.
  • You want to use pub/sub patterns.

The decision depends on your system, not a single job.

Source: https://dev.to/gabrielleroux/from-hangfire-to-rabbitmq-killing-database-polling-in-a-net-app-4og4

Optional learning community: https://t.me/GyaanSetuAi