---
title: "Benchmarks"
description: "Every published figure with its conditions, and the hardware behind it."
---

> Queen MQ documentation, for AI agents
> Complete self-contained summary of Queen MQ: https://queenmq.com/llms-brief.txt
> Fetch that first when the question is about the product rather than about this page.
> Index of all pages: https://queenmq.com/llms.txt

# Benchmarks

A number appears here only when an archived artifact under `benchmark-queen/` records what
produced it: the loader's stdout, the configuration line it printed, the host shape, the broker
build.

## The runs

| Run | Headline | The conditions that make it true |
| --- | --- | --- |
| [Throughput 24h 1M](/benchmarks/soak-24h) | 86,369,975,300 messages in 24 hours, about 1,000,000 msg/s per side, 0 restarts, broker resident memory flat at ~4.1 GB | **Explicit acks** (leased pops), **deduplication on** (60 s window), 200 partitions, 600 consumers, push batch 100, 256-byte payloads, 32 vCPU / 62 GiB, Queen 1.0.0 |
| [A million ordered partitions](/benchmarks/cardinality-1m) | 1,000,000 ordered partitions in one queue, created during the run at 1,000/s, serving 200,000 msg/s with 0 push, pop or ack errors | **Explicit acks** (leased pops), retention on with `RETENTION_PARALLELISM=16`, **deduplication off**, 1,000 partitions active per second rotating through the space, 300 consumers, 32 vCPU / 62 GiB, Queen 1.0.0. One hour, of which 43 minutes on the completed space |
| [Ordered pipeline](/benchmarks/ordered-pipeline) | 88,503,408 messages verified across 4 stages and 1000 partitions with 0 duplicates, 0 gaps and 0 order violations | 25,000 events/s for 600 s, deduplication window 300 s, explicit bulk acks, per-stage verifier over per-property logs |
| [Multi-tenant cell](/benchmarks/multitenant-cell) | A 2-core cell behind the proxy holding above 2400 msg/s with zero loss; 12 tenants for 1 hour with zero cross-tenant deliveries | **Deduplication off**, **429 retry disabled**, enforcement on, all tenants sharing one queue and one consumer group |
| [Laravel supervisors](/benchmarks/laravel-supervisors) | Queen Rust master PSS 2.9 MiB against Horizon's 65.0 MiB; 307.67 against 294.30 completed jobs/s | **Diagnostic only:** Docker Desktop arm64, four workers, 2,000 jobs with 10 ms work, three runs per engine, prefetch 4 without the renewal helper now required for production |

Also: [cross-broker comparison](/benchmarks/comparison) and
[method, rig and archive](/benchmarks/method/).

## The other evidence

How fast one shape goes is one kind of evidence. Whether the clients and the broker agree about
what the API means, on more than one topology, is the other.
[Conformance](/benchmarks/conformance) is that matrix: six client suites on three topologies
each, the broker's own unit tests, an HA mesh assertion and a two-tenant isolation suite recorded
at 45 assertions and 0 failures, every cell in its own throwaway stack. The harness itself, and
how to run a subset of it, is [Testing](/internals/contributing/testing/).

## How to read a figure

Producers are open-loop: each push leaves at its scheduled instant and is shed over the in-flight
cap rather than queued behind it, so a pacer that falls behind shows up as latency. Every
archived run reports `shed=0`. Consumers are closed-loop drainers: their throughput is a result,
not an offered load.

Broker-side p99 is the time the broker spent on a request it accepted. End-to-end p99 also spans
the network, the commit and the wait in the partition, so it belongs to the workload. The
multi-tenant hour recorded both: a broker-side median p99 of about 2.9 ms against an end-to-end
p99 of 133,693 ms, the rate-limited tenants' backlog in the same histogram.

## Hardware

| Rig | Used by | Shape |
| --- | --- | --- |
| Single-node bench | Throughput 24h 1M, the ordered pipeline | Broker and PostgreSQL 18 co-located on 32 vCPU / 62 GiB, loaders on separate machines, three of 16 vCPU for the soak. `fdatasync` about 70 µs on the soak host, 68 µs on the pipeline host |
| Cell rig | the multi-tenant runs | 8 vCPU / 15 GiB with NVMe, `fdatasync` average 95.5 µs and p99 about 396 µs. PostgreSQL, the proxy's state database, the broker and the proxy share **one CPU-capped systemd slice**: a free-tier shape is 2 cores for all four, loader outside it |

Source: https://queenmq.com/benchmarks/index.mdx