---
title: "Archived results"
description: "The pre-1.0 benchmark sessions, measured on the retired C++ broker or the retired storage engine, enumerated so an old link or an old claim can be traced, and marked as not comparable to 1.0."
---

> Documentation Index
> Fetch the complete documentation index at: https://queenmq.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Archived results

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.

> **Danger**
>
> Nothing on this page is comparable to 1.0, and nothing on it may be quoted for 1.0. Two entire
> implementations were replaced: the C++ broker (uWebSockets, libuv, libqueen, the `queen.messages`
> row store) and, after it, the segments storage engine (`queen.seg_*`). The broker in 1.0 shares
> no code with the first and no schema with the second. A figure measured on either is a figure
> about software that is not shipped.

The publishable results are on [Benchmarks](/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 |

> **Caution**
>
> The internally circulated storage-engine improvement ratios (the "6.2× storage, 5.2× consume,
> 16× retention" figures from the segment-engine spike) are not published anywhere on this site.
> The spike's directory is not in this tree at all, so there is no artifact to check them against,
> and they compared two engines of which one is retired and the other was itself replaced.

## 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](/benchmarks/peak) |
| `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](/benchmarks/multitenant-cell), 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.md` in 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 from `2026-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.html` and `benchmarks-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](/benchmarks/soak-24h) |
| Peak throughput | [Throughput ceiling](/benchmarks/peak) |
| Ordered multi-stage pipeline | [Ordered pipeline](/benchmarks/ordered-pipeline) |
| Small-host and multi-tenant capacity | [Multi-tenant cell](/benchmarks/multitenant-cell) |
| How to run any of it | [Reproducing these runs](/benchmarks/reproduce) |

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