Why We Built DurableStack: A Database-Native Approach to Background Jobs
Most background job libraries look similar at the API level. Here's why we took a different architectural path focused on distributed safety, observability, and low operational overhead.
The Problem with Traditional Background Job Tools
If you've built production services, you've probably used (or considered) Hangfire, Quartz.NET, or similar libraries. They're mature, battle-tested, and solve real problems.
But as we scaled our own systems, we kept running into the same friction points:
- Queue sprawl and extra infrastructure -- Distributed workers by managing Redis, RabbitMQ, or dedicated job servers adds complexity and failure points.
- Distributed execution gotchas -- Race conditions, duplicate processing, and tricky worker reclaim logic when instances crash or scale.
- Observability gaps -- Job state often lives in a separate system from your application telemetry, making it hard to correlate failures.
We knew we could build something better.
Our Philosophy: Database as the Source of Truth
DurableStack treats your existing SQL database as the coordination engine for background work -- not just storage.
This isn't "yet another job scheduler." It's a distributed execution runtime designed from the ground up for modern, containerized, multi-instance applications.
Key design decisions:
- Lease-based claiming + heartbeats for safe multi-worker execution.
- No external brokers required for most workloads -- your database already has strong consistency guarantees.
- First-class OpenTelemetry + event sinks so observability stays in your control (with optional hosted dashboards for convenience).
- Consistent contracts across future runtimes (.NET today, TypeScript and Python planned).
What This Means for You in Practice
- Deploy the same way you deploy the rest of your app.
- Scale horizontally without worrying about job duplication or lost work.
- Get rich production visibility without stitching together multiple tools.
- Start free. Pay only when you need advanced operational features (longer retention, more alerts, team controls).
We're Building in Public
This is just the beginning. v1.0.1 marks our first stable release, but the vision is bigger: a family of runtimes with shared semantics so teams can standardize background job patterns across languages and services.
We'd love your feedback -- whether you're evaluating alternatives, running into distributed job challenges, or have ideas for the roadmap.
Try it today:
What background job pain points are you dealing with in your systems? Drop a comment or open an issue -- your real-world experience will help shape what comes next.
Built with love for .NET (and soon beyond) teams who want reliable background work without the ops tax.