TL;DR
BullMQ is a job queue library with retries, delayed jobs, and parent/child dependencies through Flows. It uses Redis by default and also supports PostgreSQL. OpenWorkflow runs multi-step processes as functions backed by PostgreSQL or SQLite. Wrap each operation in a step, and OpenWorkflow saves its result so completed steps aren’t re-run after a failure.What This Looks Like in Practice
An order process reserves inventory, charges a payment, and sends a receipt. If sending the receipt fails, here’s what happens on retry:
In either system, a process can crash after a payment succeeds but before
saving that success. Use an idempotency key with the payment provider so a
retry can’t charge twice.
See Steps for how OpenWorkflow saves results and replays a run.
When OpenWorkflow is the Better Fit
- Multi-step workflows: You want to write one function and track its steps as one workflow run, with saved results and retries for each step.
- SQLite: You want a local database file for development or a single-server app. Use PostgreSQL when you need workers across multiple machines.
When BullMQ is the Right Call
- Simple fire-and-forget jobs: If you’re sending emails or processing uploads with no dependencies between jobs, a queue is the right tool. You don’t need workflows for that.
- Existing Redis setup: If your team already runs Redis and your jobs are straightforward, the adoption cost of BullMQ is low.
- Job dependency trees: Your process fits a tree of parent/child jobs, and BullMQ Flows provide the coordination you need.