Inngest vs BullMQ + Durabull: model the actual cost

Translate business work into billed executions

Inngest’s published calculator uses executions = runs × (steps + 1). One function run with five step.run() calls therefore consumes six executions. One million such runs produces six million executions; it is not covered by an allowance of one million executions.

Make a workload inventory before estimating. Separate simple notifications from multi-step workflows, assign a monthly run count to each class, and count the steps actually reached along each branch. A single global average can hide an expensive minority of long workflows. Keep retry and replay behavior explicit and validate the resulting units against a pilot’s billed usage.

Step boundaries also carry operational value. Inngest persists completed step results so a resumed workflow can avoid repeating completed work. Consolidating every operation into one step solely to reduce the count can reduce the precision of recovery. Price the implementation you would actually trust in production.

const workload = [
  { name: 'notifications', runs: 800_000, steps: 1 },
  { name: 'account-onboarding', runs: 200_000, steps: 5 },
]

const executions = workload.reduce(
  (total, item) => total + item.runs * (item.steps + 1),
  0,
)
console.log(executions) // 2800000

Separate known plan prices from unknown overages

The published Pro plan starts at $99/month with one million executions. Business starts at $499/month with ten million. Those are plan allowances, not prices per million business jobs. At those exact execution volumes, the base plans cover the execution count, subject to their other limits.

For 100 million executions, this guide does not publish a definitive bill. Inngest describes tiered Pro overage rates that fall from $0.000050 to $0.000015 per execution as volume grows, but the reviewed page does not publish the tier breakpoints needed to reproduce that invoice. Use the current calculator or obtain a quote; do not multiply the lowest advertised marginal rate across every execution.

Keep events, concurrent steps, workers, seats, observability, and any sandbox compute as separate estimate lines. A workload fitting an execution allowance can still exceed another resource limit. Save the dated plan assumptions next to the estimate so a future reader can update them without reconstructing the model.

Build the BullMQ side from measured resources

For Redis-backed BullMQ, estimate Redis capacity and availability, worker compute, network traffic, backups, telemetry, and engineering operations. Durabull’s hosted dashboard is free to start, but that does not make the underlying workload free. Durabull is Apache-2.0 open source; self-hosting it adds its own deployment costs.

Use the same job mix, payload sizes, retention, peak arrival pattern, and recovery target on both sides. Measure CPU time and memory for your processors; a large idle worker fleet and a highly utilized fleet produce very different costs per completed job. Include retained failed jobs when sizing Redis, especially after a prolonged dependency outage.

Distinguish incremental cost from total cost. An existing BullMQ fleet may have spare capacity, making the next workload inexpensive to add. A greenfield comparison must include provisioning and maintaining that fleet. Both are valid questions, but they cannot share one unlabeled savings percentage.

Price recovery and maintenance as scenarios

Build a normal month, a growth month, and an incident month. For each, record successful work, retries, retained failures, peak concurrency, and operator time. Use your own hourly cost assumptions and label them as assumptions. Avoid claiming an industry-wide operational savings rate from a single team’s experience.

A useful worksheet has one row per cost category and separate columns for measured usage, unit price, fixed allowance, and uncertainty. Mark unknown amounts as unknown. A blank price is more honest and actionable than a fabricated zero: it tells you which trial or vendor conversation is still needed.

Include the effort to implement equivalent semantics. If you require persisted multi-step progress, long waits, or coordinated recovery, estimate that implementation on BullMQ rather than comparing only a simple queue consumer with a durable workflow.

Choose based on the work you need to own

Keeping BullMQ is attractive when you already have reliable processors and want better operational visibility. Inngest is attractive when its workflow model removes work your team would otherwise build and maintain. The right outcome can be to retain existing queue workloads while evaluating a new orchestration model for a separate feature.

Before a migration decision, implement one representative workflow, cause a controlled failure, recover it, and review the resulting usage and operational effort. A small observed comparison is more decision-useful than projecting a headline unit price across a hundred million hypothetical jobs.

Common questions

Sources & review

Written by Durabull. Reviewed 20 October 2026 against the references below and Durabull’s implementation. Pricing examples are documented models, not measured benchmarks or vendor quotes.

Suggest a correction if a feature, price, or documented behavior has changed.

Compare the options

• Durabull vsInngestReplaces BullMQ. Cloud bills executions (run + each step). Official MCP inspects Inngest runs, not Redis queues.
• Durabull vsTrigger.devReplaces BullMQ. Trigger.dev Cloud runs your task code and bills compute-seconds plus $0.000025 per run.
• Durabull vsTemporal CloudReplaces BullMQ with Workflows and Activities. Actions cost $50 per million on the Developer plan.
• Durabull vsHatchetReplaces BullMQ. With a card on file, 1M runs and 1M events are free each month, then $30 per million runs.