Queen 1.0 is a Rust broker on a PostgreSQL log engine. Most of the benchmark history in this repository predates one or both of those. This page exists so that a number found in an old README, an old badge, an old slide or an old link can be traced back to the implementation that produced it, and so that it is unambiguous which side of the line it falls on.
The publishable results are on Benchmarks. Everything below is history.
Measured on the retired C++ broker
These sessions ran a C++ broker binary: server/bin/queen-server, built with make, tuned with
NUM_WORKERS and SIDECAR_POOL_SIZE, storing messages as rows in queen.messages. None of
that exists in the tree.
| Directory | What it was |
|---|---|
2026-04-25/ |
A 14-hour production-load run on a single host, image 0.14.0.alpha.3. One markdown report and one chart |
2026-04-26/ |
The largest of the old campaigns: 18 short benchmarks across four axes (partition count, batch size, queue count, consumer group count), plus a version comparison between 0.14.0.alpha.3 and 0.12.19, plus two four-stage pipeline reports (one ordered at 1000 partitions, one throughput-tuned at 10). Includes its own HOW-TO-RUN.md |
2026-06-04/ |
A throughput campaign with sustained-soak findings and a metrics and observability remediation plan |
2026-06-06-engine-scaling/ |
An investigation into whether one libqueen push and ack engine was enough, or whether the libuv event loop saturated before PostgreSQL did. The question is meaningless in 1.0: there is no libqueen and no event-loop engine count |
2026-06-07/ |
A 24-hour soak on the C++ 0.16 “new architecture”, with a comparison against the April results. This is the session behind the figures the repository README.md still displays, and behind the 0.16 soak pages of the retired documentation site |
simd-vs-0155/ |
A comparison of SIMD JSON parsing against release 0.15.5, a C++ hot-path change |
json-uuid-profile/ |
JSON and UUID handling profiles on the C++ broker |
fusion-hysteresis/ |
A sweep harness for the C++ fusion and hysteresis behaviour, with a Node pacer |
pgmq/ |
A comparison against another PostgreSQL-backed queue, measured on the C++ broker. Not quotable in any form: this site makes no performance comparison against any other system, precisely because every such comparison this project published was measured on the retired implementation |
test-perf/ |
A scenario-based harness that started ./server/bin/queen-server with NUM_WORKERS and SIDECAR_POOL_SIZE under CPU and memory caps. The binary and both variables are gone |
Measured on the retired segments storage engine
These ran on a newer broker but against queen.seg_*, the segments engine that preceded the log
engine. The log engine is a greenfield replacement with no data migration, and
040_log_drop_legacy.sql drops every seg_* object at boot. So these numbers describe a schema
the current broker actively removes.
| Directory | What it was |
|---|---|
2026-07-17-storagev2-soak/ |
A hot-path spike and segments soak, with the C++ broker built from the storage-v2-slice branch. Carries the retired 023_storage_v2.sql and 024_storage_v2_pop_ext.sql alongside its outputs. The VM was destroyed afterwards, which is why the scripts and logs were archived here |
2026-07-22-local-decay/ |
A local investigation into what prevented the segments broker from saturating PostgreSQL, plus deduplication and retention behaviour under decay |
On the current engine, but still not publishable
These ran on the Rust broker with the log engine, so they are recent. They are still excluded, for reasons that have nothing to do with the implementation.
| Directory | Why it is not quoted |
|---|---|
2026-07-22-vm-ab/ |
An A/B between the retired segments engine and the log engine. One arm is retired software, and the session’s own record notes that hypervisor CPU steal swung single runs by about ±22%, which is larger than the effect being measured |
2026-07-23-openloop/ |
The session that produced this project’s best headline number. Its stdout was not archived, so the configuration cannot be checked against the result. Its own configuration line records deduplication off. Superseded for publication by the archived 600-second run on Throughput ceiling |
2026-07-24-freetier-vm/ |
A free-tier capacity study measuring broker and PostgreSQL only, with no proxy in the path and no tenancy enforcement, as its own note says. Superseded by the cell runs, which cap the whole cell including the proxy |
2026-07-24-tenants/ |
A sizing study of many small tenants, useful for capacity planning and not a throughput or correctness result. It also predates tenancy enforcement |
2026-07-25-chaos-partial/ |
Explicitly incomplete. The chaos controller died after its first PostgreSQL stop and did not restart it, so PostgreSQL was down for about two hours unintentionally; log files from the earlier, clean cycle were deleted during restart attempts. The session’s own note calls the run compromised and says the test must be redone. Its observations are interesting and are not evidence |
Old links and old claims
If you are chasing a figure, these are the places it probably came from:
README.mdin the repository root. Still shows a 0.16-era soak chart and 0.16-era throughput figures, and still points at the retired documentation site’s 0.16 benchmark pages. Those come from2026-06-07/and are C++ numbers.benchmark-queen/README.md. A pre-1.0 index. It summarises only the April sessions and states a throughput envelope and pipeline results from them.- The retired documentation site under
docs/. Its benchmark pages (benchmarks.html,benchmarks-2026-04.html,benchmarks-0.16-soak.html,benchmarks-0.16-matrix.htmlandbenchmarks-0.16-lag.html) are all pre-1.0. - Anything phrased as a comparison with another broker. All of it was measured on the C++ implementation.
What replaced them
| Old question | Current answer |
|---|---|
| Long-running stability | 24-hour soak |
| Peak throughput | Throughput ceiling |
| Ordered multi-stage pipeline | Ordered pipeline |
| Small-host and multi-tenant capacity | Multi-tenant cell |
| How to run any of it | Reproducing these runs |