Comparisons
Honest positioning against Temporal, Inngest/Trigger.dev, and BullMQ — including the cases where they're the better choice.
The short version#
| ZenZip | Temporal | Inngest / Trigger.dev | BullMQ | |
|---|---|---|---|---|
| Infrastructure | none (embedded SQLite) → Postgres | server cluster + DB | their cloud (self-host secondary) | Redis |
| Durable workflows | ✅ step memoization | ✅ deterministic replay | ✅ step memoization | — (flows ≠ durability) |
| Queues | ✅ built in | via workflows | ✅ | ✅ (the gold standard API) |
| AI agents | ✅ durable, first-class | — | partial / SDK add-ons | — |
| Where code runs | your process | your workers + their cluster | your handlers, their orchestration | your process |
| Scale ceiling | 1 box → Postgres multi-node | very high | managed for you | Redis cluster |
vs Temporal#
Temporal is the most battle-tested durable-execution system in existence, and at massive scale it remains the safer bet. ZenZip differs in two deliberate ways:
- No cluster. Temporal means operating (or paying for) a server fleet plus its database before your first workflow. ZenZip is
npm install; the engine lives in your process. - No replay determinism rules. Temporal re-executes your whole function on recovery, so
Date.now(), random numbers, and bare I/O corrupt replays — the #1 source of user pain. ZenZip journals step results instead: between-steps code is plain TypeScript with no special rules (how it works).
Choose Temporal when you need multi-region failover, years-long run retention with strict audit, or polyglot workers today.
vs Inngest / Trigger.dev#
Closest relatives — both proved that step functions are the right developer experience, and ZenZip's step API deliberately rhymes with theirs. The difference is the deployment model:
- They are platforms; ZenZip is a framework.Their orchestration state lives in their cloud (self-hosting exists but is the second-class path). ZenZip's state lives in a SQLite file you can open, back up, and ship — or your own Postgres.
- Offline and air-gapped work. Tests, CI, laptops on planes, on-prem deployments — no callback URLs, no tunnels, no dev servers proxying events.
- One runtime, more primitives. Queues, schedules, state machines, an event outbox, and durable agents share one engine and one dashboard instead of being separate products.
Choose them when you want orchestration as a managed service with zero servers of your own and a team dashboard out of the box — that is genuinely their job, and they do it well.
vs BullMQ#
- BullMQ is an excellent queue. ZenZip's queues cover the same ground (retries, backoff, priorities, delays, rate limits, batches, DLQ) without Redis— and sit under workflows and agents that BullMQ doesn't attempt.
- BullMQ flows chain jobs but don't give you durable multi-step functions with sleeps, event waits, and memoized recovery.
- Raw throughput at extreme scale favors Redis. ZenZip's embedded store handles ~10k jobs/s worst-case on a laptop — beyond most apps, but if you're saturating Redis clusters, you're not the target user yet.
When NOT to use ZenZip#
Honesty section
Skip ZenZip (for now) if any of these are true:
- You need it battle-proven today. This is a pre-1.0 alpha. The chaos suites are real, but production miles are not yet.
- Sustained six-figure jobs/sec. Postgres mode scales out, but extreme-throughput queueing on dedicated brokers is a different design point.
- Polyglot workers. Node-only until a Python SDK lands (post-1.0 backlog).
- Serverless-only deployment. The engine wants a long-lived process; Lambda-style execution is hostile to embedded runtimes.