One Nearest-Neighbour Query Is Dozens of Serial Reads
Once a vector collection exceeds memory, the neighbour lists of a graph index such as HNSW must live on SSD. A query walks dozens of hops, reading one neighbour block per hop, and the hops are strictly dependent — the result of one determines where the next reads from. Queue depth is therefore inherently shallow, often QD1 to QD4, with block sizes between 4KB and 16KB. Bandwidth barely helps: query latency equals per-read response time multiplied by hop count, with nothing in between that can be parallelised away.
Which Line on the Spec Sheet Matters
On the same sheet, 1,500 KIOPS of 4KB random read and a 65 µs QD1 average read latency describe two different things. The first is concurrency — how many queries the drive can carry at once. The second is the latency base of a single query, and a serial chain consumes only that. Worse, production services are judged on P99, and a serial chain amplifies the tail: if any one of thirty hops lands on a slow path the whole query is slow, and the probability of hitting one accumulates with hop count. The X9 series J990X and J995X are positioned for Gen5 ultra-low latency and high endurance, and together with the low-latency QoS baseline in firmware the goal is to narrow the right tail of the read latency distribution rather than shave a few microseconds off the mean.
The Build Phase Spends the Endurance Budget in One Go
The index build profile is nearly the inverse: bulk sequential writes mixed with highly concurrent random reads, sustained for hours or days, with cumulative write volume several times the size of the dataset. Endurance consumption is concentrated and severe. In CORE 7, J750 plans for 1 DWPD over five years and J770 for 3 DWPD, and that gap becomes plainly visible wherever indexes are rebuilt often. Size for the query profile alone and the build phase turns into either the bottleneck or the endurance risk; the two phases of one system simply do not share an optimum. These figures are engineering planning targets, being validated model by model on the internal engineering platform JH-E4U-C.
How to Benchmark So the Numbers Mean Something
Copying a generic benchmark produces misleading conclusions: pushing queue depth to 32 to chase peak IOPS yields a number with no relation to the real query path. What is useful is holding QD1 to QD4, capturing the full latency distribution separately at 4KB and 16KB, reading P99 and P99.9 rather than the mean, and repeating the run with background reclaim active and the drive close to full — two conditions that hold permanently in production and never appear in a fresh-drive benchmark. Telemetry can archive each capture so that reproduction and attribution do not depend on a single run.