I wanted to share a library that I think deserves more attention in the .NET background jobs space: Jobby.

Jobby v1.0.0 was released on April 11, 2026, and at this point it looks like a serious option to evaluate alongside Hangfire, Quartz, and TickerQ, especially if performance, PostgreSQL efficiency, and execution control matter to you.

Jobby logo

Jobby logo

What Stands Out in Jobby

What stands out in Jobby for me:

  • multi-queue support
  • sequential execution inside groups via SerializableGroupId
  • recurring jobs with cron, interval-based scheduling, and custom schedulers
  • transactional job creation, including a good fit for transactional outbox scenarios
  • configurable middleware pipeline
  • built-in OpenTelemetry metrics and tracing
  • MIT license

The main pitch of Jobby is pretty clear: it was designed with optimization in mind from the start, both on the .NET side and on the database side.

From the project’s published benchmarks and benchmark code, Jobby appears to outperform Hangfire and Quartz in several scenarios, while also using less memory and putting less CPU pressure on PostgreSQL. I did not find benchmark evidence against TickerQ though, so I would not make that claim yet.

Why the v1.0.0 Release Matters

The v1.0.0 release makes the library feel much more complete. The biggest additions are:

  • Multi-queues: useful when you do not want one type of workload to delay another, and when different queues need different parallelism settings.
  • Grouped sequential execution: jobs in the same logical group can be processed strictly one by one, while unrelated groups keep running in parallel.
  • More flexible recurring jobs: in addition to cron, Jobby now supports interval-based schedules, custom schedulers, and non-exclusive recurring jobs.

This combination is what makes Jobby interesting to me. It is not just a simple scheduler. It is trying to cover real production concerns: retries, distributed execution, scheduling, observability, queue isolation, and ordered processing.

A Real-World Use Case from My Side

Using this occasion for a small side plug: I built a Telegram reminder bot called KindlyRemindly (@KindlyRemindlyBot), and it has been using Jobby since the very early days of the library.

It is not a high-load system, so this is not a planet-scale endorsement or anything like that. But Jobby has been running there reliably in production for about half a year and has been doing its job very well.

One of the features that mattered most to me, and that I had discussed with the author before it landed in v1.0.0, is grouped sequential execution.

In my bot, some Telegram updates from the same user must be processed strictly one by one, while updates from different users should still run in parallel. In practice, that means:

serialize by userId, parallelize across userIds

I spent quite a while looking for a clean solution to that problem and even tried Hangfire, but I could not find a built-in equivalent for this exact scenario. Jobby’s SerializableGroupId model is a very natural fit for it.

What I particularly like about this feature is that it solves a real coordination problem without forcing everything through a single global bottleneck. You preserve ordering where it matters, while still keeping good parallelism across unrelated workloads.

That opens the door to more than just Telegram bot updates. The same pattern is useful for:

  • ordered per-user processing
  • per-aggregate workflows
  • outbox and event-driven pipelines
  • background jobs where business consistency matters more than raw parallelism inside a single entity stream

Current Limitations

To be fair, Jobby still has some obvious limitations today:

  • there is no dashboard UI yet
  • PostgreSQL is the only storage provider right now

So it is not trying to win on every axis today. If a built-in dashboard or multiple storage providers are must-haves for your stack, that is a real limitation.

Still, if you care more about throughput, consistency, queue control, and extensibility than about having a polished built-in dashboard today, Jobby looks very promising.

Would be great to hear what people think about it. I am sure the author, fornit1917, would also appreciate any feedback.

And of course, contributions are welcome. There is still a lot to build, so ideas, issues, and pull requests would be greatly appreciated.