In a September 2026 test on an Apple M1, 8DB loaded five million time-series readings, containing 50 million metric values, and made them queryable in a median 2.56 seconds. QuestDB took 5.16 seconds in the same recorded campaign. That is approximately twice the loading throughput for the tested configurations.[1]
The timing included the work needed to make the data queryable. For 8DB, that meant receiving and parsing the input, sorting it, building flat-leaf pages and a learned index. For QuestDB, it included applying the incoming data until it could be queried. Both arms used buffered ingestion, without a power-loss-safe completion guarantee during the load. Client configurations differed: 8DB used four HTTP writers; QuestDB used one TCP stream.
That result matters because the useful finish line for a data system is the point where an application can do something with its data. Here, the recorded 8DB configuration shortened that wait to roughly half the comparator's time on the same M1 machine.
8DB also supports protected persistent storage and describes recovery testing over committed data in its fielded-systems engineering record.[10] The buffered completion boundary above belongs to this loading experiment. For a production deployment, we select the supported path and acknowledgement policy around what the application must retain, protect and recover.
Our TSBS history also makes a broader engineering point: the path a database takes through a workload can change its performance dramatically. Understanding that path is how we turn a benchmark into a useful design decision.
From construction speed to usable data
How long until the data is queryable?
Five million readings, containing 50 million metric values.
Median · Seconds to queryable · Lower is better
Test configuration
- Both databases
- Apple M1 · 16GB RAM
- Dataset
- 5M readings · 50M metric values
- 8DB client
- 4 HTTP writers
- QuestDB client
- 1 TCP stream
- Completion
- Data queryable; buffered loading
- Repetitions
- 3 recorded rounds
Reported ingestion throughput, with the hardware in view
Selected results from different environments. These bars compare reported magnitudes; they do not establish a like-for-like database ranking.
Millions of readings / rows per second · Higher is better
8DB: M1 laptop
8 CPU cores4 performance + 4 efficiency
16GB RAM5M readings · 4,000 hosts
4 HTTP writers · macOS
September 2026
Published server tests
32 physical CPU coresAWS r8a.8xlarge · AMD EPYC
256GiB RAM69.12M rows · 4,000 hosts
32 workers · Ubuntu 22.04
August 2026
TSBS, the Time Series Benchmark Suite, separates data generation, loading and query execution. Its CPU-only workload includes ten metrics per reading. Our results discussed here cover specific TSBS-shaped workloads and custom harnesses; they are not a claim of completing every official TSBS workload.[2]
An earlier campaign explored how quickly 8DB could build its specialized time-series representation in memory. On April 7, ten recorded M1 runs each constructed a dataset of ten million metric entries. Recalculating throughput from the surviving durations gives a mean of 61.285 million entries per second, with a sample coefficient of variation of approximately 1.34%.[3]
A second campaign on April 14 retained ten invocation means for the same named ten-million-entry benchmark. The mean of the corresponding rates was 60.092 million entries per second, approximately 2% below the April 7 mean.[4] These campaigns provide a historical reference for the component measurement. Without a matched competitor construction test, they do not establish its competitive standing; the difference between dates also does not isolate a software regression.
These are in-process, memory-backed construction measurements. The April 7 report explicitly excludes the confidence and governance processing from that fast path. They show the speed of the representation-building work under those conditions; the September campaign asks the additional question of how quickly incoming network data becomes queryable.
| Recorded campaign | Work being measured | Result |
|---|---|---|
| April 7, M1 | In-process construction of 10M metric entries, ten runs | 61.285M entries/sec, mean of per-run rates |
| April 14, M1 | Same named 10M construction benchmark, ten invocation means | 60.092M entries/sec, mean of per-invocation rates |
| September 8, M1 | Network bulk load of 5M readings / 50M values through queryability | 2.56 sec median for 8DB; 5.16 sec for QuestDB |
The rows describe different measurement boundaries. Reading them together explains how component speed relates to a usable ingestion pipeline; they are not one continuous speedup curve.
Why the representation matters
The specialized path arranges sorted keys and values into compact flat leaves. Queries can read values at known offsets rather than reconstructing a general-purpose object for each entry. A learned index helps locate the relevant pages. Bulk construction also gives the engine an opportunity to organize a batch together.[3][5]
That is a useful architectural choice for time-series loading. The larger ambition for 8DB is to give workloads an appropriate representation and execution path within a connected database, while retaining the relationships needed to use their results elsewhere.
The history shows why choosing the execution path matters. A separate transactional ingestion test exercised per-frame transactions and a different transport through RAM-backed I/O. It exposed serialization work to optimize; it was not a measurement of the cost of power-loss-safe persistence. The bulk campaign instead exercised a path built for loading time-series data together.[1] Preserving both records lets us identify the work an application needs and optimize that work.
For someone evaluating a database, the practical question is specific: which path will my application actually use, and what has it completed when the timer stops?
A correctness check changed the result we could defend
The first September bulk sweep recorded fast timings but failed its aggregate checks. Some requested hosts returned empty results; another returned an incorrect average. We exclude those arms from successful-output comparisons.[6]
The campaign report attributes the defect to a learned-index prediction window being trusted beyond its valid range. It describes a repair that checks the prediction and falls back to a full search when needed. The subsequent sweep marks all three 8DB arms and all three QuestDB arms as verified against the harness’s selected checks.[1]
| Round | 8DB time to queryable | QuestDB time to queryable |
|---|---|---|
| 1 | 2.62 sec | 5.00 sec |
| 2 | 2.54 sec | 5.16 sec |
| 3 | 2.56 sec | 5.79 sec |
The report describes exact counts and selected host-level minimum, maximum and average checks, with an additional sum check for QuestDB. That is meaningful validation within the harness’s scope. It does not establish that every possible query was tested.
The approximately twofold comparison comes from the displayed median times: 5.16 divided by 2.56. It describes this M1 campaign, its buffered loading boundary and its differing client configurations. These are historical results, not a fresh measurement of today’s build.
Hardware, operating systems and controls belong in the result
Our retained history spans M1/macOS, an AMD 7800X3D PC campaign and an EC2 campaign. They should remain separate platform observations until the build, workload and execution conditions are aligned.
For example, an April 8 raw output archived under the 7800X3D campaign records a central estimate of 279.97 milliseconds for the named 10M construction benchmark. The April 7 M1 series averaged 163.198 milliseconds. The archive preserves that difference; it does not isolate its cause. Build configuration, operating system, allocation behavior, background work and the exact harness are among the variables that need to be reconciled before calling it a processor advantage.[7]
This is why I want performance history to preserve configurations and conditions rather than leave us with one number attached to each machine.
8DB also has controls intended to adapt its behavior to the workload. The inspected source provides write policies, configurable flushing and an adaptive mechanism that adjusts a node’s epsilon parameter at split time from observed read/write counts. In plain language, the engine can change how much work it buffers before passing that work onward.[8]
The inspected source separates this buffering policy from commit durability.[8] That distinction matters commercially: execution can be tuned for the workload while the required completion contract stays explicit. A faster buffering policy does not, by itself, mean weaker persistence. We record the active path, settings and acknowledgement boundary together so a customer can evaluate the configuration their application will actually use. These TSBS measurements do not isolate the adaptive mechanism's contribution.
The energy question is comparative: joules for the same completed job
The April M1 records say the machine was running on battery. That is useful deployment context. The surviving battery-percentage readings do not provide the calibrated energy measurements needed for a measured joules-per-result comparison.[3]
The useful question is how much energy 8DB and QuestDB each consume to complete the same job with the same guarantees. Lower joules per completed job would establish an energy advantage. A standalone power reading would not answer that question.
The September timings suggest a comparative hypothesis worth testing: 8DB's shorter loading interval could reduce energy relative to QuestDB. The calculation depends on their average whole-system power. At equal average power, the recorded times imply about 50% less loading-interval energy; at 1.5 times QuestDB's average power, about 26% less. At approximately 2.02 times its power, that modeled advantage disappears.[9] We have not measured which of these conditions applies.
These are calculated scenarios, not observed power savings. They need dedicated follow-up benchmarking with measured system power, matched starting states and durability, and an accounting of deferred work after queryability. Faster completion creates an opportunity to save energy; the measurements must establish whether 8DB realizes it.
I want future comparisons to put time to a correct, usable result alongside measured energy, memory and storage work. A change that saves writes may add CPU work. A faster configuration may use more power. Preserving those tradeoffs lets us choose a configuration for a real device and workload.
The practical result is fast access to newly loaded data on a 16GB M1 laptop: the recorded bulk configuration made the dataset queryable in roughly half QuestDB's time under the conditions above. For a customer, the next step is to bring the workload and the required guarantees. We can evaluate the appropriate 8DB path against both, measuring useful throughput alongside recovery and protection. A durable deployment needs its own matched performance measurement; the value is choosing and testing the right configuration for the job.
If you work with time-series data, what must be complete before your application considers an ingestion finished? That boundary is the starting point for a comparison worth making.
Evidence and methods
-
September 8 campaign: report and retained second-sweep log. MacBook Pro M1, 16GB; QuestDB 10.0.1; 4,000 hosts, 1,250 readings per host, ten metrics per reading. Three interleaved rounds, 8DB first in each round. Recorded load averages were approximately 9–11. Different HTTP/TCP client concurrency is part of this configuration comparison. Transactional-path report retains the separate CYC36 outcome. Exact September binary and harness identity remain a reproducibility gap in the recovered package.
-
TSBS project documentation describes the generation, load and query phases and ten-metric CPU-only readings. The September campaign uses a custom deterministic generator and harness; no official leaderboard placement is claimed.
-
April 7 reproducibility report. Retained raw durations range from 159.80 to 166.27ms for ten million metric entries. The original script’s throughput printing failed; recalculation from its surviving durations reproduces approximately 61.3M entries/sec. Reported environment: M1, 16GB, macOS 26.2, memory-backed SimulatedIo, abbreviated revision 76f56f2. This reconstruction verifies arithmetic, not a new execution of the historical binary.
-
April 14 campaign folder. Structured results identify revision 3aaa8423e5afef7987ff533de9870c28120d71aa, M1/macOS, release profile and battery power. All eleven recorded benchmark mean durations were recomputed from their ten invocation means. Mean throughput is the mean of each invocation’s reciprocal duration, not dataset size divided by mean duration.
-
Flat-leaf and learned-index path described in the April 7 report and inspected 8DB source. Mechanism explains the intended work reduction; this article does not assign a measured fraction of the total gain to each component.
-
First-sweep log explicitly marks the 8DB arms invalid. Failed results remain in the history, separate from accepted-output timing comparisons.
-
Retained April 8 artifact:
trustdb-bench-pc-7800x3d-20260408/raw/04_tsbs.txt, SHA-2564bfc6af7e6df311c4e636df916f664ff9f843ff89933014846d8309d58f821a4. The platform association comes from its archive path; full build and environment binding is incomplete. These observations are not a controlled ARM-versus-x86 or operating-system comparison. -
Inspected 8DB source:
src/tree/tree.rs(WritePolicy,TreeConfig) andsrc/tree/aet.rs(compute_epsilon_at_split). Source identity and exact copies are retained in the private article evidence package. Implementation presence does not establish engagement in a historical benchmark or an energy-saving outcome. -
Scenario equation:
E8DB / EQuestDB = (average_power8DB / average_powerQuestDB) × (2.56 / 5.16). At equal power, the ratio is 0.4961; at 1.5× power, it is 0.7442. Break-even power ratio is 5.16/2.56 = 2.015625. Inputs are displayed historical median durations, not paired power/energy measurements. This is a loading-interval model, not a measured energy distribution, whole-job saving or battery-life prediction. Preparation, idle baseline, post-load work and sampling uncertainty require a dedicated protocol. -
8DB protected persistence and recovery describes sealed storage and simulated crash/power-loss recovery over committed data within its evaluator scope. This is a separate engineering record, not a durability validation of the September TSBS bulk harness. Build with 8DB describes acceptance workloads with matched protection and durability requirements. The retained transactional TSBS report identifies SimulatedIo; transactional acknowledgement in that test must not be equated with power-loss-safe media persistence.
Continue the technical conversation
Where could this help your work?
Bring a research question, a database workload or an application you want to build. Let’s connect the ideas in this article to an evaluation that matters to your team.
Discuss this work