Questions about benchmark evidence, current metrics, and the proven / not yet proven boundary.

Benchmarks and Proof Q&A

Finnish counterpart: Benchmarks and Proof Q&A

What current metrics are actually verified in this document?

Likely question

What has really been verified right now?

Short answer

Verified items include the live chain on July 1, 2026, the active compacted base, pointer generation 9, deltaRangeReads = 0 in the active public chain, and the real 10M-row R2 benchmark object.

Longer answer

The strongest currently verified benchmark object is:

10,000,000 rows
362,903,909 bytes, about 346 MiB
storage: a real Cloudflare R2 object
query path: Worker + deterministic range reads

Do we already have one-week production telemetry?

Likely question

Do you already have a one-week p50/p95 production table?

Longer answer

This document does not include an invented “one week production metrics” section. The honest current state is:

the live chain, pointer, manifest, and benchmark endpoint are verified
the 10M R2 benchmark object is verified
the current live briefing baseline is verified
a unified week-long p50/p95 telemetry package is still next-phase measurement work

What do the benchmarks actually show?

Likely question

What does the current remote 10M JRI4 benchmark actually show?

Short answer

It shows that a 10M-row, roughly 346 MiB R2 object can be queried without loading the whole object, and that hot query paths stay around 4-8 range reads.

Longer answer

Current presentation query modes:

materialized_top   4 reads   2.23 KB   166 ms
indexed_top        6 reads   10.38 KB  238 ms
source_filter      4 reads   2.21 KB   143 ms
timestamp_range    4 reads   2.40 KB   148 ms
source_index       7 reads   14.20 KB  261 ms
timestamp_index    8 reads   16.40 KB  284 ms

The architectural interpretation is:

from a roughly 346 MiB object, only 2-17 KB are read depending on query mode
rangeReads stays around 4-8 on known hot paths
the bottleneck is now more R2 round-trip latency than object size

What is the current live briefing baseline?

Likely question

What about the real current live briefing path?

Short answer

The current live briefing baseline is still heavy in an honest sense: 148 rows, indexed_top, 22 range reads, 87.88 KB bytes read, and about 950 ms.

Longer answer

This matters because it shows two things at the same time:

the delta-chain collapse was fixed with compaction
the hot path is still too heavy if the goal is a very strong R2-native UI-query claim

What does the row-summary prototype show?

Likely question

What does the row-summary prototype really tell us?

Short answer

It shows that the right optimization direction is to change the artifact structure, not just micro-tune Worker code.

Longer answer

With the row-summary prototype:

bytesRead dropped by about 45%
rangeReads dropped from 22 to 19

But at the same time:

this is not yet a killer benchmark
19 range reads is still too much for the strongest R2-native UI claim
the next real solution is a materialized public-card / top-briefing segment

What is proven / what is not yet proven?

Proven: Worker + R2 + pointer + manifest + base/delta chain works, a 10M/346 MiB JDBIN object can be queried through a deterministic range-read path, and snapshot delivery works on top of the canonical storage layer.

Longer answer

What is proven:

Cloudflare Worker + R2 + pointer + manifest + base/delta chain works in practice
a 10M-row, roughly 346 MiB JDBIN object can be queried through a deterministic range-read path without loading the full object
the live briefing path can be published on top of one compacted base
JDBIN works as an auditable canonical storage/read layer

What is not yet proven:

no unified week-long p50/p95 production telemetry yet
no 100M-row or 5GB-scale production query path yet
no final lightweight live UI-query hot path yet
not a general SQL replacement
not a formalized consensus model or claim-level fact checking
not yet a fully finished editorial product

Benchmarks and Proof Q&A

On this page