Skip to content

Benchmark · Source-backed analysis · scoped evidence · conceptual artwork

One Engine, Specialist-Level Performance: What the Benchmarks Show

8DB's time-series loading, vector search and combined queries have each produced strong results against named alternatives. The useful question is where that performance changes what you can build.

Published
Reading time4 minutes
Database architectureNative capabilitiesBuyer evaluation
Two laptops display matching shipping-data examples beside a large stopwatch and a performance test log.
Visual thesisA controlled comparison of the same useful job. Imagined test scene; hardware, screens and stopwatch are not the recorded benchmark setup or results.

8DB answered a combined shipping query about 31× faster than SurrealDB in our benchmark.

That is meaningful evidence for an omnimodal database: native breadth can come with competitive execution. A team building around observations, relationships, location and similarity has a reason to evaluate one engine for more of the application.

The three campaigns below were run separately, with different configurations and completion guarantees. Their peaks were not measured together.

Explore the three comparisons below, including how a higher vector-recall requirement changes the result.

Measured comparisons · September 2026

Three jobs. Three performance comparisons.

8DB beside the alternatives tested. Each panel has its own units, hardware and completion boundary.

Time-series ingestionLower is better ↓

Median seconds until the data is queryable

8 September · 5 million readings · 50 million values · Apple M1, 16 GB

8DB
2.56 s
QuestDBVersion 10.0.1
5.16 s

Three recorded rounds. 8DB: four HTTP writers; QuestDB: one TCP stream. Both used buffered loading without power-loss-safe completion during the load.

TSBS campaign, conditions and retained timings →
Vector searchHigher is better ↑

Median searches per second at a chosen quality floor

18 September · 99,488 real 768D text embeddings · Eight clients · Ryzen 9 9950X3D / WSL2

Minimum recall@10

99% minimum recall@10

8DBActual recall: 99.043%
8,551
QdrantActual recall: 99.531%
4,682

The required quality changes the choice. At the strictest tested floor, 99.98%, Qdrant reached 1,445 searches/s and 8DB 1,100. The 8DB point observed 100% recall; Qdrant observed 99.980%. Fully indexed readiness also favored Qdrant: 18.3 s with up to eight build threads, versus 166 s with one 8DB build thread.

Fastest tested points meeting each floor; actual recall differs. Five timing passes on one graph per engine. Warmed, unfiltered retrieval; shared host, 2 GiB per server, unmatched CPU quotas/affinity. Native TCP and an in-memory 8DB index versus prepared gRPC and a restarted persisted Qdrant 1.19.1 index. Durability and governance were not matched.

Vector campaign, quality curve and measurement notes →
Composed shipping queryLower is better ↓

Median milliseconds to the complete decoded answer

18 September · Relationships + time + location + sustained heat · Same Ryzen 9 9950X3D / WSL2 host · Four logical CPUs per server

8DBTyped time-series route
10.803 ms
SurrealDBVersion 3.2.4
332.455 ms

Synthetic, resident-memory corpus of 743,999 readings. Twenty timed HTTP/JSON requests per engine with exact-answer checks. Custom Rust composition over native 8DB operations versus tuned SurrealQL; preparation, authentication and durable completion excluded.

Shipping query, tuning and full-answer comparison →
All chart values and sources
Independent campaigns; throughput values rounded to whole searches per second
Measurement8DBComparator
Time-series load2.56 sQuestDB: 5.16 s
Vector, 99% floor8,551 /s
99.043% recall
Qdrant: 4,682 /s
99.531% recall
Vector, 99.5% floor5,516 /s
99.766% recall
Qdrant: 4,682 /s
99.531% recall
Vector, 99.9% floor3,383 /s
99.961% recall
Qdrant: 2,228 /s
99.922% recall
Vector, 99.98% floor1,100 /s
100.000% observed recall
Qdrant: 1,445 /s
99.980% recall
Shipping answer10.803 msSurrealDB: 332.455 ms

Machine-readable vector evidence · Retained TSBS timings · Retained shipping analysis

Separate vendor-run campaigns, not an aggregate ranking or a simultaneous mixed workload. All bars start at zero; axes have different units and scales. Results describe the tested paths and configurations. Unmeasured alternatives are not assigned speeds.

Get incoming observations into use

The time-series result measures a useful milestone: when an application can query newly loaded data.

On a 16GB Apple M1, the September campaign loaded five million readings containing fifty million metric values. The median of three rounds was 2.56 seconds for 8DB and 5.16 seconds for QuestDB 10.0.1. Both completed the harness's selected correctness checks. Campaign and retained timings.

8DB used four HTTP writers; QuestDB used one TCP stream. Both used buffered loading, without guaranteeing survival of power loss at that finish line. The result therefore describes those loading configurations. It gives an application team a concrete starting point for evaluating bulk imports, catch-up work and the wait before fresh observations become useful.

The specialized 8DB path organizes incoming values into compact pages and builds an index for finding them. That is one way a broad engine can still give a particular workload a specialized representation.

Choose vector speed at the quality you need

Similarity search has another finish line: returning sufficiently accurate neighbors.

In our text-embedding campaign, the fastest tested configurations meeting a 99% recall requirement delivered 8,551 searches per second for 8DB and 4,682 for Qdrant. Actual recall differed: 99.043% and 99.531%. Recall here means recovering the exact nearest neighbors, not judging whether a search result answers a human question. Results and public measurement supplement.

The workload used 99,488 normalized, 768-dimensional Wikipedia embeddings, 512 passage queries and eight clients. Both services had a 2 GiB memory cap on a shared Ryzen 9 9950X3D workstation under WSL2. CPU quotas and affinity were unmatched. 8DB served a derived in-memory index over TCP; Qdrant 1.19.1 served a persisted, restarted index through prepared gRPC requests.

At the strictest tested 99.98% recall floor, Qdrant led: 1,445 versus 1,100 searches per second. It also reached fully indexed readiness in 18.3 seconds with up to eight construction threads, against 166 seconds with one 8DB thread.

Those differences affect the choice. A stable index serving many searches can amortize construction; frequent rebuilds make readiness more important. The evidence supports strong 8DB retrieval at useful operating points while preserving the cases where Qdrant was ahead.

Ask the complete question

The combined shipping workload comes closest to the reason for an omnimodal engine.

It asks which ships, owned through a company's subsidiaries, experienced sustained overheating inside a chosen area during a month. Answering requires relationships, time, temperature, location and a sequence test. A missing hourly reading must break the sequence; an isolated spike must not become a sustained event.

Across a synthetic fixture of 743,999 readings, 8DB's typed time-series route returned the complete answer in a median 10.803 milliseconds, compared with 332.455 milliseconds for tuned SurrealDB 3.2.4. Both returned matching ships and qualifying timestamps. Complete query and methods.

Each server could use the same four logical CPUs on a Ryzen 9 9950X3D workstation. The timer covered the HTTP request through the decoded JSON answer. Data was already prepared and resident; authentication and durable completion were outside this experiment. 8DB used custom Rust composition over native operations, while SurrealDB used a tuned SurrealQL record-range layout.

One measured optimization makes the opportunity tangible. Checking temperature first let 8DB avoid fetching coordinates for ships that could not qualify. A separate tuning experiment found that selective reads and additional workers each helped while preserving exact answers. That explains some useful engineering choices; it does not attribute the entire competitive gap to one architectural feature.

What the portfolio changes

Together, these results make 8DB worth considering when an application needs several capable data models and the performance to use them. The combined query shows native operations cooperating on an actual question; the other campaigns establish additional strengths separately.

Buyers have credible alternatives. Qdrant supports hybrid and multistage retrieval. PostgreSQL with pgvector keeps vectors alongside relational data, joins and transactions. SurrealDB integrates multiple data models. Their capabilities belong in a shortlist even where this portfolio supplies no matched timing.

For 8DB, keeping more work within native representations could reduce transfers and intermediate data that an application maintains. That opportunity needs measurement in the deployed workflow. These campaigns do not establish whole-application cost savings, energy savings or the performance of a protected, durable version of every path.

Bring one non-sensitive question your application must answer, a representative data sample and the conditions that make the answer useful: quality, freshness, completion time and recovery. Evaluate that workload with us. We can start from the relevant measured path and compare the complete job your users need.

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

Continue reading

The next layer of the argument.