---
title: Why DurableStack
description: Why DurableStack exists and how it differs from traditional .NET background job tools.
order: 11
---

# Why DurableStack

I built DurableStack because I wanted background job infrastructure that felt simple to adopt but was designed for real distributed production environments from the beginning.

## The problem this solves

- In many systems, background work starts simple and then grows into multi-instance deployment.
- At that point, correctness and operational visibility become the hard part.
- I wanted a runtime that stays practical for small teams while scaling into distributed execution without changing core architecture.

## How DurableStack compares to tools like HangFire

DurableStack and HangFire solve related problems, but DurableStack intentionally emphasizes a few design choices:

### 1) Built for distribution from day 1

- Lease ownership, reclaim behavior, and worker identity are first-class runtime concerns.
- The default mental model assumes multiple workers and rolling deployments.
- This keeps scaling behavior predictable instead of being an afterthought.

### 2) Free observability website

- You can connect runtimes to the hosted DurableStack observability site at no cost.
- This gives teams run visibility, failure insight, and trend data without building internal dashboards first.
- It is optional, but available immediately.

### 3) Uses only your existing database to coordinate runs

- DurableStack coordinates job execution using the database you already operate.
- Supported providers include PostgreSQL, SQL Server, SQLite, and MySQL.
- There is no required sidecar queue system to run the core runtime.

### 4) No new or external runtime dependencies required

- You do not need Redis, RabbitMQ, Kafka, or a separate orchestration service just to run jobs.
- Adoption can start inside an existing .NET service and existing deployment model.
- Optional integrations (observability, telemetry export) layer on top instead of becoming required infrastructure.

## What this means for a future developer

- The runtime model is consistent from local development to distributed production.
- Operational behavior is explicit instead of hidden behind implicit infrastructure assumptions.
- The same codebase can evolve without introducing a second operational stack just for background jobs.