18 tests. 1.6 billion message events. Zero loss.

All numbers on this page come from benchmark sessions run on 2026-04-25 and 2026-04-26 on a fresh 32 vCPU / 62 GiB host with PostgreSQL upstream postgres:latest, Queen 0.14.0.alpha.3, Apache Kafka 3.7 (KRaft single-node), and RabbitMQ 3.12. Each test ran for 15 minutes against a fresh server state. The full raw data, per-minute time series, Postgres stats, system metrics, autocannon and perf-test output, lives in benchmark-queen/2026-04-26.

Headline

Test environment

Throughput & latency together

Throughput numbers without latency are half the story. Here are the four push configurations side by side, with both the producer and consumer latency profiles:

Partition scaling, the Queen claim, validated

Same producer concurrency (5×100 connections), increasing partition count from 2 to 10 001. If partitions were physical commit-logs, this would degrade catastrophically. In Queen they're logical lanes, so the cost is index size, not state machine size.

Partition count goes up by 5 000×; throughput drops by 29%. Zero errors at every scale. This is the curve that lets Queen offer "one partition per chat conversation" in production without operational drama.

Time-series stability, what 15 minutes of bp-10 looks like

Throughput averages don't tell you whether a system is stable or oscillating. Below is the per-minute pop rate from bp-10's own queue-ops.json output, a rendering of the actual time series.

Per-minute throughput bounces between 35k and 46k msg/s for 14 minutes, then ramps down as the producer hits its target. No drift, no degradation, no warm-up artifact. The same is true of every sustained test in the suite.

Consumer-group fan-out

Multi-tenancy is essentially free

Same total client load, distributed across one queue vs ten queues:

Routing to ten different queues instead of one was slightly faster (less contention on the single partition's advisory lock), well within noise. Multi-tenant deployments don't pay a partitioning tax.

Realistic pipeline, producer → worker → q2 fan-out

The throughput numbers above are pure broker-side push/pop micro-benchmarks. Most real workloads look different: multiple stages, real client SDK with batching and long-poll, work simulation between stages, multiple downstream consumer groups. This benchmark exercises that shape end-to-end with the official queen-mq JS client and pm2:

[producer ×2] ──push──▶  pipe-q1  ──pop──▶  [worker ×7] ──push──▶  pipe-q2 ─┬─pop──▶ [analytics ×7]
                                                                              │
                                                                              └─pop──▶ [log ×7]

Producer pushes single messages per HTTP call. Each worker pops a batch from q1, simulates 5–20 ms of long-tail per-message work in parallel via Promise.all, forwards the batch to q2 preserving per-partition ordering, then acks q1 (at-least-once: separate push then ack, no transactional commit). Both analytics and log consumer groups drain q2 with the same shape, fan-out, simulated work, batch ack. The whole thing runs on a 16 vCPU / 64 GB DigitalOcean VM with PG synchronous_commit=on.

Same engine, same client, same pipeline shape, two configurations of the partition knob:

In the throughput-tuned config Postgres CPU is 3.2× lower at nearly double the throughput, bigger batches amortise the per-call SQL overhead so much that the per-message PG cost collapses. The system is then producer-bound, not PG-bound: adding more producer processes would push the rate well into the 30–50 k/s range without changing anything broker-side. Full writeups with reproduction recipes: pipeline-queen.md (high-cardinality) and pipeline-queen-throughput.md (throughput-tuned).

Queen vs Kafka vs RabbitMQ, same hardware, same payload

Single-node, 1 000 partitions/queues, persistent durability, 15-min run, ~28-byte message payload, same 32 vCPU / 62 GiB host. All three measured directly: Kafka with kafka-producer-perf-test.sh, RabbitMQ with the official pivotalrabbitmq/perf-test. Each system uses its own native binary protocol (HTTP/JSON for Queen, Kafka wire protocol, AMQP for RabbitMQ).

Detailed cross-system reports: vs-kafka.md · vs-rabbitmq.md

What broker benchmarks miss, your workers are usually the bottleneck

Every benchmark on this page measures broker capacity. But most production workloads aren't broker-bound. If your messages do real work, a database write, an API call, an LLM inference, a webhook delivery, your consumer fleet becomes the bottleneck long before the broker does. That changes which system matters, and by how much.

Here's the math at 20 ms of work per message (representative of a typical DB write or moderate API call). One worker processes 50 msg/s. Useful throughput equals workers × 50 msg/s:

*Rough estimate at small-EC2 / small-container per-worker pricing. Real cost depends on your stack and what each worker does.

Said differently: at a real workload of 5 k msg/s, all three systems sit at low utilization on the broker side:

When the broker isn't the bottleneck, what actually matters is:

• Latency at low load, Queen ~5–10 ms p99 (unsaturated), Kafka ~5–10 ms, RabbitMQ ~3–5 ms. Roughly tied. The “Kafka 39× faster than Queen” comparison was for saturated brokers; nobody runs production workloads saturated.
• Operational cost, Queen is 1 binary + your existing PG. Kafka is broker cluster + KRaft + topic admin + monitoring stack. The annual operational difference dwarfs the broker license/hardware cost.
• Durability semantics, Queen's synchronous_commit=on default is the strictest of the three. Kafka with acks=1 isn't equivalent; matched durability (acks=all + flush.messages=1) cuts Kafka throughput by 5–10×.
• Integration with your stack, Queen lets you do BEGIN; INSERT order; queen.push(...); COMMIT; in one PG transaction. The transactional-outbox pattern (a real cost in Kafka deployments) goes away.

The broker comparison only matters when work per message is sub-millisecond: true streaming pipelines (Kafka Streams, Flink, ksqlDB), log shipping, click-stream analytics. For those, Kafka is the right tool and nothing else competes. For everything else, order processing, notifications, webhooks, ML inference jobs, chat handling, workflow steps, the broker sits idle, the worker fleet sets your cost, and the differentiator is what's easy to operate and integrate.

Resource efficiency

The most consistent signal across all 18 tests: Queen is small.

Adaptive concurrency in action

Queen ships with DB_POOL_SIZE=50 by default. Across the entire benchmark suite, including the 100k msg/s peak test, the libqueen Vegas controller kept the active connection count at ~2.5. The other 47 connections sit idle in the pool, available as overflow for transient spikes.

This is exactly what the TCP-Vegas-style controller is supposed to do: when adding in-flight work doesn't reduce RTT, the controller knows the pipe isn't congested and stays put. You can't manually tune your way to a better number for this workload, the controller already found it. See the architecture page for the math.

0.14 vs 0.12, adaptive engine impact

Same five tests, run once on each version, fresh DB:

Pop throughput improved 80–90% under partition contention, the single biggest win from the libqueen rewrite. PG memory usage 30–70% lower for the same workload. PG deadlock mode under heavy fan-out eliminated.

Data integrity, the headline number

Bugs we found

Honest accounting. Four issues surfaced during the run; all four are cosmetic, none caused data loss. Listed here because a benchmark page that doesn't tell you what broke isn't useful.

Reproduce it yourself

All raw data, runner scripts, configs, and analysis live in the repo: benchmark-queen/2026-04-26. Each test directory has the per-consumer logs, queue-ops time-series JSON, postgres stats, system metrics, and final docker-stats output. The HOW-TO-RUN.md walks through reproducing the entire suite step by step (Docker images, PostgreSQL tuning, autocannon configuration).