Message queue services and background jobs, compared
Each provider is profiled from its own documentation, with the source recorded against every figure. No two of these bill for the same thing — operations, messages, executions, credits — so the included allowance names its own meter rather than pretending to be a comparable number.
Queues and background jobs
| Provider | Message retention | Max message size | Max delay | Concurrency |
|---|---|---|---|---|
| Amazon SQS | 4 days by default; configurable from 60 seconds up to 14 days per queue. | 256 KB per message. A single request carries 1 to 10 messages up to 1 MiB total, and each 64 KB chunk of payload is billed as one request. | 15 minutes maximum per-message delay (message timer) or per-queue delay; default is 0 seconds. | Approximately 120,000 in-flight messages per standard queue (received but not yet deleted); API call rate on standard queues is nearly unlimited. |
| Azure Queue Storage | 7 days by default, set per message with messagettl; since version 2017-07-29 it can be any positive number, or -1 for a message that never expires. | 64 KB per message. A queue may hold millions of messages, bounded only by the storage account's capacity rather than a queue-level ceiling. | Time-to-live defaults to seven days and can be set to any positive number, or to -1 for a message that never expires — the only queue here with an unbounded option. | Not documented |
| Cloudflare Queues | 4 days by default on Workers Paid, configurable up to 14 days. Workers Free is fixed at 24 hours. | 128 KB per message, with roughly 100 bytes of that taken by internal metadata. | 24 hours, set with delaySeconds when sending or retrying. | 250 concurrent consumer invocations, push-based only, with per-queue throughput capped at 5,000 messages a second. |
| Google Cloud Pub/Sub | Retention is configurable and charged rather than granted: $0.27 per GiB-month for messages a topic is configured to retain, for snapshots, and for a subscription's backlog older than one day. A subscription's default retention is 7 days. | Pub/Sub bills on bytes rather than message count; the pricing page states no per-message size ceiling and prices throughput and storage instead. | Not documented | Not documented |
| Hatchet | Run history, logs and traces stay queryable for 1 day on Pay-as-you-go without a card, 7 days with a card on file, and 90+ days on Custom. This is dashboard and API history, not how long an undelivered task waits in the queue, so no magnitude is recorded. | 4 MB default maximum payload size for a task's input or output between worker and Hatchet engine. | Not documented | 2,000 worker slots (tasks running at once, totalled across all workers) on Pay-as-you-go without a card, 10,000 with a card on file; Custom gets dedicated capacity. No requests-per-second ceiling is published. |
| Inngest | Queue depth rather than a time window: 100,000 queued items on the free plan and 1,000,000 or more on Pro. Trace retention is 7 days on Pro and 90 on Enterprise. | 4 MiB per step-returned payload; 32 MiB total function run state; 10 MiB hard cap per event batch. | Step sleeps up to 1 year on paid plans; the free plan supports sleeps up to 7 days. | 5 concurrent steps on the free plan, 100 or more on Pro, custom on Enterprise. |
| Temporal | Closed workflow Event History is kept for a Retention Period set per Namespace, up to 90 days on Temporal Cloud; longer needs the Export feature. Business includes 2.5 GB Active and 100 GB Retained Storage. Recorded without a magnitude: this is workflow-history retention, not how long an undelivered message survives. | 2 MB maximum payload per request (each Workflow/Activity argument or return value); 4 MB per Event History transaction, non-configurable. | Timers (durable sleeps) may run up to 100 years in Temporal Cloud. | 500 Actions per second per Namespace by default, auto-scaling above that with On-Demand Capacity; 20,000 Activity and 20,000 Workflow Task pollers per Namespace. |
| Trigger.dev | Log retention of 1 day on the free plan, 7 days on Hobby and 30 days on Pro, with the query period matching. | 3 MB per trigger payload (each batch item up to 3 MB on SDK 4.3.1+); task outputs up to 10 MB; payloads over 512 KB offloaded to object storage. | Not documented | 20 concurrent runs on the free plan, 50 on Hobby, and more on Pro at $10 a month per additional 50. |
| Upstash QStash | Dead letter queue retention of 3 days on the free plan, 7 days on Pay as You Go, 30 days and 3 months on the fixed plans. | 1 MB on the free plan, 10 MB on Pay as You Go and 50 MB on the fixed plans. | 7 days on the free plan; 1 year on Pay as You Go and unlimited on the fixed plans. | Not documented |
| Zeplo | 30 days of log retention on every plan — free, Company and Enterprise alike. The longest window in this category by a wide margin. | 256 KB inline request body (unlimited via S3 offload); plan payload caps are 64 KB on Developer and 1 MB on Company. | 30 days (2,592,000 seconds) maximum delay_seconds per request. | API rate limit rather than a concurrency figure: 100 requests/min on Developer (Free) and 2,000 requests/min on Company ($39/mo). |
Which to consider
AWS-resident systems that want a queue with a permanent free million requests a month and no capacity to plan — SQS scales without a throughput setting to choose.
Azure-resident systems that want a queue billed like storage — operations plus depth, no plan to choose and no capacity to provision.
Workers applications that want a queue with no egress or throughput charges and a retention window measured in days rather than hours.
Google Cloud systems that want messaging without capacity planning — throughput is metered rather than provisioned, and 10 GiB a month costs nothing.
Task workloads that want a countable unit and no plan fee: 1M task runs and 1M events free each month with a card on file, then $30 per million runs, with 10,000 concurrent worker slots before any contract.
Multi-step workflows that need durable execution and retries between steps, rather than a bare queue you write a consumer for.
Long-running, stateful workflows where losing execution history is the failure that matters — Temporal keeps event history as first-class storage rather than logs that expire.
Teams that want background jobs written as normal code with the bill expressed as compute credits rather than a per-message meter.
HTTP-first workloads that want scheduling and delay measured in months rather than a day, without running a consumer process.
Turning an HTTP endpoint into a queued, retried job without running a consumer — and keeping a month of logs while doing it, which nothing else here offers on a free plan.
Queues and background jobs in the news
- Amazon Bedrock AgentCore Ambient Agents Move AI Beyond the Chat Prompt - remio
- Announcing 90-minute function timeout on AWS Lambda Managed Instances | AWS Compute Blog - Amazon Web Services (AWS)
- How to Build a REST API for an AI Application - Oracle Blogs
- Microsoft Open-Sources PostgreSQL Extension for In-Database Durable Execution - infoq.com
Comments are hosted by EchoThread, which sets cookies and offers social sign-in. Like the analytics on this site, it does not load until you accept — see the privacy page.