Queen MQ
Benchmarks

Measured, reproducible, on real hardware.

Every number here comes from a real run on a 32 vCPU / 62 GiB host with PostgreSQL at the strictest durability tier (synchronous_commit=on), a fresh database per test, and all raw data published in the repo. The current engine is Queen 0.16 (the pushser architecture); below are its headline benchmarks plus the archived earlier runs.

Soak volume 10.4 B messages in 24h
Sustained rate ~119k msg/s push and pop
Matrix vs 0.14 10 / 11 cells faster · up to 3×
Lost messages 0 across both runs

Queen 0.16: current results

The pushser rework is built for sustained, balanced load. In a full-day soak it held ~119k msg/s of push and pop for 24 hours, 10.4 billion messages, zero push errors, and flat ~400 MiB broker memory (the long-run stability the older architecture lacked). Re-running the April matrix on the same hardware, it's faster on 10 of 11 cells (1.3-3.0×) and, crucially, keeps throughput flat as partitions scale to 10,000 where 0.14 declined. And when a realistic application is deliberately over-provisioned on push (2× consumer-group fan-out driven past the consume ceiling for an hour) it degrades gracefully: producers never block, nothing is lost or reordered, and the backlog stays bounded and self-draining.

0.16 · Durability soak

24 hours · 10.4 billion messages

~119k msg/s sustained Balanced push + pop for a full day, zero loss, flat broker memory. Includes the live dashboard at the 24h mark. 0 errors~400 MiB broker100% PG cache
0.16 · Throughput & scaling matrix

Same suite, new engine

10 / 11 cells faster Batch sizing, partition scaling to 10k, and consumer-group fan-out vs the 0.14 baseline on identical hardware. 171.6k peakflat to 10k part2.9× fan-out
0.16 · Behavior under overload

Over-provisioned push: what happens when producers outrun consumers

0 lost · 0 errors · 1h, 43.2M msgs, 2× fan-out A realistic app (fan-out, explicit ack, 20 ms handlers, failures + DLQ, transactional pipeline) driven above the consume ceiling for an hour. Producers never block, order holds, and the backlog stays bounded and self-draining. Graceful degradation, not breakage. 0 push errors~1.3 core brokerbounded backlogself-drains

All benchmarks at a glance

VersionWhenHeadlineReports
0.16
pushser		 Jun 2026 24h soak: 10.4B msgs at ~119k/s, zero loss, flat memory · matrix 1.3-3.0× vs 0.14, flat partition scaling · over-provisioned-push lag test: 0 loss, bounded self-draining backlog soak · matrix · lag
0.14
0.14.0.alpha.3		 Apr 2026 18 tests, 1.6B events, zero loss · 104k peak · head-to-head vs Kafka 3.7 & RabbitMQ 3.12 · 0.14-vs-0.12 archive

Older benchmarks

April 2026 · v0.14

The original suite + Kafka / RabbitMQ

18 tests across throughput, latency, partition scaling, fan-out, multi-tenancy and a realistic pipeline, plus a direct head-to-head against Kafka 3.7 and RabbitMQ 3.12 on the same hardware, and a 0.14-vs-0.12 comparison.
Sizing

How much Postgres do I need?

An interactive calculator turning your target msg/s into a PostgreSQL vCPU budget, derived directly from these benchmarks.

How we benchmark