bunqueue vs BullMQ, one less server.

Benchmark results comparing the bunqueue TCP server against BullMQ with Redis on identical workloads, a feature comparison, and the cases where BullMQ is still the better pick.

This page helps you decide between bunqueue and BullMQ. Short version first, then the numbers with their caveats, then features.

Quick answer

Pick bunqueue if you run on Bun and want embedded/single-broker SQLite or a PostgreSQL 15–18 multi-broker server without Redis; 18.6 is recommended. You get the same Queue and Worker API across these server backends.

Pick BullMQ if Redis/Redis Cluster is already your operational standard, you need Redis-specific behavior, or you cannot run a Bun broker. Details in When to Use BullMQ Instead.

The numbers

The current measurement is on the Benchmark vs BullMQ page: bunqueue 2.9.20 against BullMQ 6.4.2 on Redis 8.10.2, on one AMD Ryzen 9 7950X3D server with the broker pinned to two cores, five measured runs per number and an exact-delivery check on every run.

In memory, bunqueue is ahead on most of the board: about 4x on bulk adds (207,601 against 52,503 jobs/s), 2.6x with 64 adds in flight, 1.3x when four worker processes drain a backlog (53,754 against 40,699 jobs/s), 1.3x on retries, and its delayed jobs start 8.5x closer to their due time (4.7 against 40.5 ms late). Median pickup latency stays under 1 ms and is ahead at every load: about 1.1x at 1,000 and 5,000 jobs/s and 1.22x at 10,000 jobs/s (0.94 against 1.14 ms). At 5,000 and 10,000 jobs/s BullMQ has the lower p99.

On disk (bunqueue on SQLite against Redis with AOF everysec), Redis is ahead today: it drains a backlog about 7x faster (33,242 against 4,491 jobs/s with four worker processes) and keeps latency flat at loads where bunqueue falls behind. Bulk adds are about level. With a million queued jobs, bunqueue holds about 2.2 GiB and Redis about 0.6 GiB.

Every row, the range of the five runs, the machine and the harness are on the benchmark page.

Where the in-memory speed comes from

TCP pipelining: many commands in flight per connection, responses matched by request id.
Batched writes: SQLite in WAL mode (write-ahead logging, a journal that lets reads and writes overlap) groups many added jobs into one disk transaction. Completing a job is still a write of its own, which is why Redis with AOF drains a backlog faster on disk today.
Sharding: work is spread across independent shards sized to your CPU cores, which keeps lock contention low.
In-memory hot path: the ready queue lives in memory (skip lists, heaps, LRU caches), SQLite is the durability layer, not the dispatcher.

Feature comparison

Feature	bunqueue	BullMQ
Queue types (standard, priority, LIFO)	✅	✅
Delayed jobs, retries with backoff	✅	✅
Dead letter queue (holding area for jobs that failed all retries)	✅ Built-in, with auto-retry and expiration	⚠️ Failed set, no dedicated DLQ
Rate limiting	✅ Per-worker and per-queue	✅ Queue-wide, set on the worker
Cron / repeatable jobs	✅ Built-in	✅ Via Job Scheduler
Parent-child flows	✅	✅
Pro-style job groups	✅ Priority/FIFO, max size, pause, limits	✅ BullMQ Pro
Native processor batches	✅ TypeScript clients, selective member failure	✅ BullMQ Pro
AbortSignal / Observable processors	✅ TypeScript clients	✅ BullMQ Pro
Pro telemetry / NestJS integration	❌ Use native metrics; framework-neutral	✅ BullMQ Pro
Persistence	Memory/SQLite by default; PostgreSQL 15–18 optional	Redis server
Horizontal broker scaling	✅ PostgreSQL mode	✅ Redis Cluster
External infrastructure	✅ None with SQLite; PostgreSQL optional	❌ Redis required
Built-in S3 backup	✅ SQLite mode	❌ Manual
MCP server for AI agents	✅ Built-in	❌
Client languages	TypeScript, Python, PHP, Go, Rust, Elixir	Node.js, Python, and community ports

When to Use BullMQ Instead

bunqueue’s SQLite mode is single-broker; its PostgreSQL mode supports multiple brokers. BullMQ is still the better pick when:

Redis Cluster is a hard requirement or already provides your queue HA model.
Redis is already in your stack and operating it costs you nothing extra.
You need Redis-specific features such as pub/sub fan-out or custom Lua scripts.
Your workers are written in languages outside bunqueue’s official SDKs.
You cannot run on Bun. bunqueue’s server and embedded mode require the Bun runtime.

Run it yourself

git clone https://github.com/egeominotti/bunqueue.git
cd bunqueue/bench/vs-bullmq
bun install --frozen-lockfile
bun src/run.ts   # Linux, Docker, Bun, Node.js and taskset; about 70 minutes

Source and method: bench/vs-bullmq.