What this page is: the procedure for confirming the findByIdRandom competitive row on the next external benchmark session — and why a single run cannot do it. This page is a protocol, not a result: it defines the evidence a claim would require.

Compliance note: the competitor row is cited as publicly available results as of 2026-09-24. All SveltyCMS figures on this page are self-measured. Comparisons are like-for-like within one harness session on the same machine and the same database (EU Directive 2006/114/EC, German UWG §6).

1. Why a single run cannot confirm the row

The lane’s session-to-session spread is ±8–30 %

The findByIdRandom lane’s session-to-session spread is documented as ±8–30 % in the Roadmap 2026. The machine-noise band in docs/reference/architecture/server-hooks.mdx shows the same effect in run-to-run form on a fingerprint-pinned build (BENCH_DOCS=10000 BENCH_CONCURRENCY=8 bun test tests/benchmarks/competitive-workload-replica.test.ts, SQLite; runs whose build artifact changed mid-flight are discarded) — three runs per side:

findByIdRandom, warm	Run 1	Run 2	Run 3	Median
sequential, before	0.430 ms	0.451 ms	0.515 ms	0.451 ms
sequential, after	0.356 ms	0.443 ms	0.469 ms	0.443 ms
8c, before	2.215 ms	2.236 ms	2.273 ms	2.236 ms
8c, after	2.266 ms	2.384 ms	2.698 ms	2.384 ms

That is ±13–20 % run-to-run noise that, in the source document’s own wording, “swallows the difference in both directions”. The single 2.698 ms outlier is the one run taken while a concurrent benchmark was active on the same machine; the same build re-measured 2.266 ms. A single session’s row can therefore sit anywhere inside a band far wider than the expected margin computed below.

The previous published row ran lane-OFF

The previous published row — 2 596 RPS on findByIdRandom — was measured on a container whose adapter-node entry (node build/index.js) never dispatched the fast-lane registry: the registry was published at boot, but only index.server.mjs consulted it, so the row was lane-OFF in all but name (Roadmap 2026).

The build patch, verified on the local replica

The build now patches the adapter-node entry at build time (adapterNodeBuildPatchPlugin in vite.config.ts) with the same lane dispatch plus the per-socket setNoDelay(true) that index.server.mjs sets. The lane functions, the state gate, the x-fast-lane: off opt-out and the BENCH_VERIFY_RAW=1 byte-identity gate are untouched (Server Hooks).

Local replica verification — same host, same bench-db Postgres, same entry node build/index.js, production mode, BENCH_DOCS=100000, 8c, replica protocol (Roadmap 2026):

Entry variant	findByIdRandom	findById	listPlain	findMissing	Control (create / update / graphql)
adapter-node, unpatched	3 013	9 125	7 817	9 363	1 531 / 1 504 / 3 247
adapter-node, patched + trims	4 470 – 4 553	13 576 – 13 640	11 822 – 13 544	16 138 – 16 937	1 563 – 1 588 / 1 463 – 1 544 / 3 252 – 3 331 (inside the ±8 % noise band)

create/update/graphql stayed inside the ±8 % noise band — the patch moved exactly the lanes it touches and nothing else. Byte-identity between the lane and the bridged fallback (point read, list, HEAD, If-None-Match → 304) was re-verified with BENCH_VERIFY_RAW=1 on the patched entry.

The projected margin is smaller than the noise

Projection for the external row: the measured lane-OFF→ON ratio at 100 k (paired 2 885 → 3 901 in the September session; 3 013 → ~4 500 on the adapter-node entry today) applied to the published 2 596 lands ≈ 3 860 – 3 900, above the published competitor row (3 551 RPS, publicly available results as of 2026-09-24) (Roadmap 2026). The margin (~10 %) is smaller than the lane’s own ±8–30 % session spread — which is exactly why the next external session must run the paired protocol instead of publishing a single run.

2. The paired protocol (external harness)

Environment. The external benchmark harness (kept outside this repository, at D:\sveltycms-benchmark\sveltycms-benchmark\) runs SveltyCMS from the ghcr.io/sveltycms/sveltycms Docker image against the stock bench-db PostgreSQL container on host port 5433 — postgres:latest 18.4, shared_buffers=128MB, no manual indexes, no partitioning. That is the same container the Scale Limits probe uses.

Steps

1. Rebuild the image from the current source. The lane dispatch is applied at build time — a stale image reproduces the lane-OFF entry. A changed adapter-node template leaves the entry unpatched with a logged warning (pattern-guarded), so the fresh build must be confirmed.
2. Run the harness at least twice, on the same machine, same dataset size, same concurrency, with no intermediate rebuilds.
3. Capture every lane in the same session: findByIdRandom plus the control lanes create, update, graphql, listPlain.
4. Compare only lanes from the same session. Never mix lanes across sessions or machines — a cross-session mix is exactly what the machine-noise band invalidates.
5. Compute the session’s own spread from the repeated sessions (the min–max range of findByIdRandom across them).

Acceptance criteria — all three must hold:

• The lane clears the competitor row beyond the spread. Every captured session’s findByIdRandom exceeds the published competitor row (3 551 RPS, publicly available results as of 2026-09-24) by more than the spread observed between those sessions.
• The controls stay put. create/update/graphql/listPlain remain inside the ±8 % noise band relative to their own prior-session values — the replica’s controls stayed inside exactly this band while the lane moved. This attributes the delta to the lane, not to the machine.
• Byte identity passes. Re-run the BENCH_VERIFY_RAW=1 gate (or its harness-side equivalent) on the measured image and record it passing.

A session that does not meet all three is recorded as not confirmed — not as a partial result.

Reporting. Date-stamp; image digest or build fingerprint; dataset size; concurrency; the per-session lane table; the competitor citation (“publicly available results as of 2026-09-24”). Self-measured rows are labelled as such.

3. Local replica — the same protocol without the external harness

The in-repo replica tests/benchmarks/competitive-workload-replica.test.ts mirrors the harness protocol: the same workload set and mixed cycle, sequential plus 8-worker concurrent phases, harness iteration counts, and a median of N rounds. This is how the adapter-node rows in §1 were produced, and how a future run stays reproducible without the external harness.

Env	Meaning	Default
BENCH_DOCS	Seeded dataset size (10000 = headline-row regime; 100000 = published-row regime)	500
BENCH_CONCURRENCY	Concurrent workers	8
BENCH_ROUNDS	Fixed round count (overrides the adaptive rounds)	adaptive
BENCH_MIN_ROUNDS / BENCH_MAX_ROUNDS	Adaptive-round bounds	3 / 7
BENCH_COV_STOP	Coefficient-of-variation stop threshold	4
BENCH_VERIFY_RAW	Byte-identity gate between the lane and the bridged fallback	off

Production mode is mandatory (mode parity): SVELTY_BENCHMARK_SERVER_MODE=production, NODE_ENV=production, BENCHMARK=true, no TEST_MODE — the measured server runs with real sessions, rate limits, WAF and audits, and only production-mode rows are comparable (Benchmarks index).

Entry points:

• Default: the replica spawns node index.cjs itself, in production mode.
• Adapter-node parity: start node build/index.js — the adapter-node entry, the one the external container runs — with the production environment, then point the replica at it with API_BASE_URL (shared-server mode). The database behind that server must already contain the seeded admin and benchmark collections (the seed the standalone mode applies via seedBenchmarkState).

# 1. Rebuild — the adapter-node patch is applied at build time.
bun run build

# 2. bench-db (the competitive harness's session Postgres) must be running:
docker start bench-db

# 3. Start the adapter-node entry, production mode:
DB_TYPE=postgresql DB_HOST=127.0.0.1 DB_PORT=5433 DB_USER=bench DB_PASSWORD=bench \
DB_NAME=sveltycms_bench NODE_ENV=production BENCHMARK=true \
SVELTY_BENCHMARK_SERVER_MODE=production node build/index.js

# 4. In a second terminal, run the replica against it (published-row regime):
API_BASE_URL=http://127.0.0.1:<port> \
DB_TYPE=postgresql DB_HOST=127.0.0.1 DB_PORT=5433 DB_USER=bench DB_PASSWORD=bench \
DB_NAME=sveltycms_bench SVELTY_BENCHMARK_SERVER_MODE=production \
BENCH_DOCS=100000 BENCH_CONCURRENCY=8 BENCH_ROUNDS=3 BENCH_VERIFY_RAW=1 \
bun test tests/benchmarks/competitive-workload-replica.test.ts

BENCH_DOCS=10000 BENCH_ROUNDS=3 matches the external headline row’s regime (Benchmarks index); BENCH_DOCS=100000 reproduces the published-row regime used for the adapter-node verification above.

4. Acceptance checklist

#	Step	Expected evidence	Acceptance criterion
1	Rebuild the image from the current source	Image digest / build fingerprint recorded; no unpatched-template warning	The container runs the patched adapter-node entry with the lane dispatch
2	Run the harness ≥ 2 sessions, same machine / dataset / c	Per-session tables	Every session captured in full
3	Capture findByIdRandom + controls (create/update/graphql/listPlain)	All five lanes present per session	No lane missing from any session
4	Compare lanes only within the same session	Same-session tables; no cross-session averaging	No mixed-session comparison in the report
5	Compute the session’s own spread	Min–max of findByIdRandom across the sessions	Spread documented, never assumed
6	Lane vs competitor row	Every session’s findByIdRandom vs 3 551 RPS (publicly available, 2026-09-24)	Exceeds the competitor row by more than the session’s own spread
7	Controls unchanged	create/update/graphql/listPlain vs their prior-session values	Inside the ±8 % noise band
8	Byte identity	BENCH_VERIFY_RAW=1 (or harness equivalent) re-run	Passes
9	Report	Dated, fingerprinted, per-session table, competitor citation	EU/DE-compliant: self-measured labelled, competitor figure dated

Related

• Benchmarks index
• Scale Limits at 1M+ Documents — the same bench-db container and reproduction commands
• Roadmap 2026 — the lane-OFF diagnosis, the build patch and the projection
• Server Hooks & Middleware — the machine-noise band and the lane attribution table