# Historical campaign excerpt

Source: M1-CYC35-LDBC-IS3-VS-NEO4J.md

SHA-256 of preserved original: 59d7bf131ff0b6ced2e8571c059513f37bbe13524d3d0fd9a0db04e0728885ab

This selected excerpt preserves the recorded table and its historical commentary. It is not an audited LDBC result. The article distinguishes service configurations, client/transport and returned data; words such as matched or ceiling in the original report are not claims of universal engine performance. The traversal log was not recovered.

## Verdict (interleaved ×3, all arms value-verified bad=0)

Hop-1 friend lookup: 5 deterministic KNOWS edges per person (`(i + j*40503) % 1M`,
j=1..5), both arms client-driven over the wire, one query per round trip, 8 workers.
8DB serves it as a prefix range scan over composite friendship keys
(`0xFD || person(8B) || friend(8B)`) through the MVCC engine's new OP_SCAN.

| arm | r1 | r2 | r3 | median | p50/query |
|---|---|---|---|---|---|
| 8DB tree engine (wire scan) | 24.2K | 23.3K | 17.9K | **23.3K scans/s** | 64–143µs |
| Neo4j 1×8 (Bolt, warm) | 1,766 | 2,001 | 2,056 | **2,001 QPS** | 3.2–3.5ms |
| Neo4j 4×8 multiproc (its best) | 4,134 | 3,990 | 4,045 | best **4,134** | ~2ms |

**Matched-8: 11.6×. Vs Neo4j's multiproc ceiling: 5.6×.** Each 8DB response is the
exact 5-edge set with byte-exact values; each Neo4j response is the exact 5 sorted
friend ids. Narrower than IS-1's 64×/284× — traversal amortizes Neo4j's per-query
overhead across 5 rows while our per-scan cost includes the BTreeMap merge and
per-row allocations (the scan path has not had the zero-alloc visitor treatment —
P07 slice 3, the named next lever).