Every number here names the work category. That is the only honest way to compare speed.
You want the headline numbers, but you also want to know what each number is allowed to mean.Number
The value and unit from the claim row.
+
Category
The work shape that makes the row comparable.
+
Non-claim
The work this number must not be used to imply.
Warm local readThe data is local and warm, so Bitfield can read known local bytes without sending a request to a separate database process.
Content address lookupBitfield first resolves the data fingerprint, then reads the bytes.
Batched write ceilingThe optimized write path divided across a full batch. Useful as a ceiling, not the same as every saved-write comparison.
Durable batch write comparisonA conservative saved-write comparison that includes more of the durable write contract.
What these numbers do not say
- They do not say cold storage is sub-nanosecond.
- They do not say the internet has zero cost.
- They do not say every database benchmark measures the same job.
- They do not say one isolated write and a full batch have the same wall-clock shape.
Claim envelopes
Each envelope is the full public shape of the claim. Quote the envelope, not just the number.| Claim ID | Public value | Measured job | Public mechanism category | Safe comparison | Do not compare with | Non-claims |
|---|---|---|---|---|---|---|
h0-warm-local-read | 0.68 nanoseconds per read | warm-local-read | memory-mapped-local-read, content-addressed-storage | Other warm local reads where the needed bytes are already available locally | Cold disk reads, networked database queries, unrelated benchmark jobs | Not a cold disk read; not a disappearing network trip; not proof that every database benchmark measures the same job |
h1-hash-lookup | 91.7 nanoseconds per lookup | content-address-lookup | content-addressed-storage | Other local content identity lookup paths | Exact-position reads with no lookup step, networked app latency | Not the same category as the H0 exact read; not networked application latency |
durable-batch-write-8190 | 316 nanoseconds per written item | durable-batch-write | durable-append-path | Other saved batch writes with a similar durability boundary | One isolated network write, vendor rows that include different durability or network work | Not every isolated write wall-clock latency; not the same category as a networked managed database write |
current-batched-write-ceiling | 0.59 nanoseconds per written item | batched-write-ceiling | durable-append-path | Other optimized full-batch ceiling rows | Every saved write path, every vendor write benchmark | Not every full saved write; not a universal write comparison row |
How to use a row in copy
Use this shape:Bitfield measuredDo not use this shape:<value> <unit>for<category>. That row is about<mechanism category>. It does not claim<main non-claim>.
Bitfield is <value> fast.
The second version removes the measured job. Once the measured job is gone, the number becomes easier to misuse.Common failures
| Failure | Why it is wrong | Fix |
|---|---|---|
| Quoting only the number | The category disappears | Quote number plus category |
| Removing non-claims | The claim gets overread | Keep the boundary sentence with the row |
| Comparing batch ceiling to every write | Ceiling is not every write | Use the durable batch row for saved-write comparisons |
| Adding a number not in the ledger | The public source of truth splits | Add the claim-ledger row first |