Most database benchmarks ask you to trust a number. 8DB is building a different kind of benchmark record: the number carries what it measures, the workload and extent, the configuration, and the path used to derive it.
That turns evidence discipline into a software capability. It gives a buyer a faster route to the question that actually matters: would this result survive on my workload, hardware and required guarantees?
8DB · A result you can evaluate
Put the conditions beside the number.
Each part answers a different buying question.
Dataset · operation · scale
Hardware · OS · settings
Buffered · queryable · durable
Comparator · matched conditions
Runs · versions · variation
Harness · raw output · status
Give each result a usable evidence record
8DB includes a native ClaimedMetric type for results intended to support a claim. It binds five things that are too often separated in a report:
- A stable identity for the result.
- The quantity being measured, such as throughput, latency, compression ratio or pass rate.
- The scope, including the dataset, the extent of the work and the configuration.
- The harness, expressed as a runnable command, an in-repository test or an explicit
Unverifiedstate. - The source revision, when the result was re-derived at a known commit.
The constructor rejects blank scope fields and values that are impossible for their declared kind. A pass rate cannot exceed one. A latency cannot be negative. The supported comparison method refuses to rank unlike quantities, so a compression ratio cannot quietly become a speedup. It also knows that lower latency and higher throughput point in opposite directions.
The display path emits the value, quantity and scope together. Copy the formatted result into a log or report and its basic identity travels with it. An inherited figure can remain visible internally as Unverified, while the type’s publication check returns false until it has a reproduction path.
This mechanism solves one specific problem: a result losing its meaning as it moves from engineering into a report, a sales conversation or an investor deck. The harness and retained raw output answer the next question: whether the work actually ran and produced the stated result. We keep those checks separate so neither a well-formed record nor a successful command is mistaken for the whole evidence chain.
The conditions make a strong result stronger
Consider 8DB’s recorded time-series comparison with QuestDB. On the same 16GB Apple M1 laptop, the tested 8DB configuration loaded five million readings containing 50 million metric values and made them queryable in a median 2.56 seconds. QuestDB took 5.16 seconds in the recorded comparison, roughly twice the wait for the tested configurations.
The conditions make that result useful rather than weaker. Both arms used buffered loading. 8DB used four HTTP writers; QuestDB used one TCP stream. The harness performed selected correctness checks after loading. It was a custom TSBS-shaped campaign, not a claim of completing every official TSBS workload.
Those details tell a buyer what the result establishes: on that M1 system, the recorded 8DB path made the tested data queryable in about half the time of the recorded QuestDB path. They also make the next evaluation obvious: run the customer’s ingestion shape, client configuration, durability boundary and queries.
Read the complete time-series comparison and evidence record.
Our protected-storage evidence uses the same discipline. In paired record-encryption tests, a 115-byte input produced 131 bytes of ciphertext with either classically established or post-quantum-established keys. The record cipher stayed AES-256-GCM-SIV in both arms. The claim concerns the encrypted record after key establishment; envelopes, signatures, framing and durable-write work have separate costs.
That boundary is why the result is useful. It isolates the architectural choice being tested instead of turning a component result into a claim about an entire deployment.
Inspect the protected-storage measurements and their scope.
Preserve the campaign, not just the winning run
A benchmark should also keep its history. Grouping runs by workload, version, hardware and configuration lets us ask better engineering questions:
- Did the result repeat?
- Which optimization changed it?
- Did an operating-system or hardware change alter the path?
- Did throughput improve while memory, recovery or result quality regressed?
- Which evidence still applies to the current build?
We are organizing 8DB’s retained benchmark campaigns around those questions. TSBS is one example. Its history includes component-construction measurements, a later network path and different machines. Keeping those records separate prevents unlike results from being presented as one continuous speedup, while retaining the history needed to tune the engine.
This is especially valuable for an omnimodal database. A time-series result, a graph traversal, an analytical query and an encrypted-store test measure different work. Their evidence can share one contract without pretending their numbers are interchangeable.
What this changes for a buyer
The usual benchmark conversation starts with a chart and ends with a debate about whether the comparison was fair. A structured evidence record moves the conversation forward:
- Match relevance sooner. See whether the workload, scale and finish line resemble your application before investing in a trial.
- Reproduce the right result. Start from the named harness and configuration rather than reverse-engineering a marketing number.
- Compare complete jobs. Put queryability, durability, recovery, energy or quality beside throughput when those outcomes matter.
- Keep tuning knowledge. Preserve slower runs and failed checks as engineering evidence instead of losing them behind the newest headline.
- Reduce claim drift. Keep technical meaning attached as a result moves between engineers, buyers, partners and investors.
No evidence model can make one benchmark universal. It can make the limits visible and the next test cheaper to design. That is the value: a performance claim becomes the beginning of a defensible evaluation, not the end of an argument.
Do not take our word for it
Bring us one consequential workload: the ingestion finish line your application needs, a query users wait on, or the recovery behavior your team must verify. We will identify the closest retained 8DB evidence, show you its scope and define the comparison that would answer your decision.
Plan an 8DB evaluation on your workload.
Evidence scope Typed metric implementation inspected · Published benchmark evidence linked. Explore the evidence.