SimpleQ vs Inngest
Different tools for different problems. SimpleQ is transport for workloads where you want to own the execution and need explicit backpressure control — LLM API calls, webhook delivery, API sync. It delivers jobs to your webhook with a three-signal ack protocol, backpressure that never burns retries, and queue templates tuned for AI workloads. Inngest is a workflow engine — it runs your functions with durable execution, step coordination, and event orchestration.
| Feature | SimpleQ | Inngest |
|---|---|---|
| Category | Managed queue (transport) | Workflow engine (durable execution) |
| Runs your code? | No — delivers to your webhook. You own the execution. | Yes — runs your functions serverlessly |
| Delivery model | Push (webhook POST) | Push (invokes your function) |
| Durable execution | No | Yes — step functions, sleep, waitForEvent |
| Retries | Configurable per queue | Configurable per step |
| Rate limiting | Per-queue fixed-window, built-in | Per-function concurrency + rate limiting |
| Ack mode | Three-signal protocol: ack (success), nack (failure with retryable flag), defer (backpressure — redelivers without burning attempts) | N/A — steps are durable |
| Backpressure | 429/503/529 auto-defers with Retry-After relay. A job can ride out 100 consecutive 429s and still complete — no attempt burned. | Step-level retry with backoff (counts against retry budget) |
| Queue templates | template: "anthropic" or "openai" — one field configures ack mode, timeout, and backoff tuned for each provider's API | None |
| Idempotency | Publish-boundary dedup — returns existing job ID on duplicate | Event-level idempotency key |
| Per-job audit trail | Full attempt history: status, error, HTTP code, timestamp per attempt | Per-step execution logs |
| Webhook signing | HMAC-SHA256 with per-queue secret | Signing key (per-app) |
| Fan-out / orchestration | No — single job delivery | Yes — step.run, step.sleep, step.waitForEvent |
| Cron / scheduling | Not yet | Yes — cron triggers built-in |
| Self-hostable | No | Yes (open-source option) |
When to choose SimpleQ
- You want to run your own code in your own infrastructure. SimpleQ delivers jobs to your webhook — you control where and how the work executes. No vendor runtime, no cold starts, no function size limits.
- Your workload is a single async operation — call an LLM, send a notification, sync to an API — not a multi-step workflow. SimpleQ's publish-deliver-ack model is simpler than learning a workflow SDK.
- Your LLM calls return 429s and you need explicit backpressure control. SimpleQ's defer mechanism holds the job and redelivers after the Retry-After delay — no attempt burned. A job can ride out a sustained API outage and still complete.
- You want one POST to configure a production-ready AI queue.
template: "anthropic"or"openai"sets ack mode, timeout, and backoff tuned for each provider's API. - You need per-job audit trails with full attempt history — not just step-level execution logs.
- You want per-queue HMAC signing secrets so different teams don't share credentials.
When to choose Inngest
- You need multi-step workflows with durable execution — step.run, step.sleep, step.waitForEvent, fan-out, and fan-in.
- You want the platform to run your functions serverlessly — no webhook endpoint to deploy and scale.
Can you use both?
Yes. Some teams use Inngest for multi-step orchestration and SimpleQ for high-volume single-job workloads where they want explicit backpressure control, per-queue rate limiting, and full ownership of the worker. SimpleQ handles the transport; Inngest handles the workflow. If your LLM call is a single step, SimpleQ is the simpler path — especially with template: "anthropic" or "openai" pre-configuring the queue.