A temperature spike is only the start of the question. Which ship produced it? Who owns that ship? Where was it, and did the heat persist long enough to matter?
We put that complete question to 8DB and SurrealDB. Using 8DB’s typed time-series APIs, the answer took a median 10.8 ms, compared with 332.5 ms for SurrealDB 3.2.4 using its recommended record-range layout. That is approximately 31× faster in this test, with both systems returning the same ships and every qualifying timestamp.
The same typed 8DB service also used about 74% less observed resident memory: 213 MiB versus 831 MiB at the recorded post-query checkpoint. Faster answers and a smaller running footprint make a more useful combination than speed alone.
This was a synthetic, resident-memory shipping workload on the same workstation, with each server restricted to the same four logical CPUs. Timings include an HTTP request and the complete decoded JSON answer. 8DB used custom Rust composition over native operations; SurrealDB used SurrealQL. Data preparation was outside the timer, and neither path required durable completion or authentication.
Twenty timed requests per engine in this comparison, with exact-answer checks. The fixture contains 743,999 readings; the selected company’s full-month window covers up to 74,399. These are repeated engineering measurements on a shared workstation, not a production latency guarantee.
One answer, several kinds of data
The query asks: which ships owned through a company’s subsidiaries had at least four consecutive hourly readings above 85°C, inside a selected North Sea rectangle, during July?
The graph identifies the ships. Time narrows their readings. Location determines whether each observation qualifies. The sequence test distinguishes sustained heat from isolated spikes.
The fresh campaign used 1,000 ships and a month of hourly observations. We deliberately removed a reading, placed one temperature exactly on the threshold and moved one location just outside the boundary. Both systems had to preserve those distinctions. A missing hour cannot silently become part of a continuous overheating sequence.
Across five fresh-process runs, we checked 1,360 timed requests against an independent answer calculation, plus 150 additional query cases evaluated on both engines. Later corrections created and removed overheating sequences, and both systems returned the revised answers correctly.
We tuned both sides
SurrealDB is a useful comparator because it also combines multiple data models and supports embedded deployment. It can express this complete question without inventing an application pipeline across several separate databases.
We tested filtering, server-side sequence calculation, secondary indexes, explicit query plans and alternative layouts. Its own documentation recommends record IDs organized around time-series ranges. Using that approach reduced its full-month query from roughly 599 ms to 330 ms in the relevant earlier comparisons. That faster layout became the final reference.
On 8DB, a simple change proved valuable: read temperature first. If a ship cannot have a qualifying hot sequence, there is no need to fetch its location samples. For candidates, retrieve the coordinates and complete the original test.
In a separate randomized experiment on the same fixture, the typed path improved from 26.8 ms with two workers and no pruning to 9.8 ms with four workers and pruning. We also tested those changes separately: adding workers helped, and avoiding unnecessary location reads helped further. Every answer remained exact.
That is a practical benefit of composing native operations: the order in which the database examines different kinds of data can remove work from the complete question.
Two useful 8DB execution choices
We also measured a faster route for prepared data.
| Full-month shipping query | 8DB | Tuned SurrealDB in the paired run | Comparison |
|---|---|---|---|
| Typed time-series route, with selective location reads | 10.8 ms | 332.5 ms | About 31× faster |
| Prepared immutable-page route | 1.95 ms | 329.5 ms | About 169× faster |
Separate fresh-process runs, each with 20 timed requests per engine. Both rows return the complete shipping answer. The prepared route uses a specialized flat-leaf and learned-index layout; the typed route uses named series and Gorilla-encoded chunks. Preparation is excluded from both query timers.
For stable, prepared data, the specialized layout is exceptionally fast in this workload. The richer typed route adds catalogs, codecs and correction support while retaining a substantial advantage over the tested SurrealDB implementation.
A smaller running footprint
The tuned typed 8DB service used approximately 213 MiB resident memory, versus 831 MiB for SurrealDB at the recorded post-query checkpoint: about 74% less, or roughly 618 MiB less for this service and fixture. This includes each process’s runtime and retained allocations, rather than just its index. It excludes the client and operating-system cache, and it is not a tested minimum-memory requirement.
Same tuned typed-route comparison. Whole-process resident memory at the recorded checkpoint, including runtime and retained allocations; client and operating-system cache excluded. This is an observed footprint, not a proven minimum device-memory requirement.
For a service competing with other workloads for RAM, a smaller footprint can create headroom. For embedded applications, it can widen the range of devices worth evaluating. Those are practical reasons to test hosting density and constrained-device deployment next; this workstation measurement does not establish an instance-size saving or Apple Watch compatibility.
Useful answers as the data changes
The typed route also passed three late-correction checks: creating a hot sequence, breaking an existing one at the exact threshold, and removing a newly created sequence. SurrealDB passed those checks too. The useful combination is the measured speed and memory advantage alongside correct revised answers, rather than a fast result that only works on immutable input. These checks demonstrate correction handling; crash recovery requires a different experiment.
Where energy and durability fit
Avoiding unnecessary location reads reduced execution work in our randomized tuning experiment. That gives us a concrete energy hypothesis: less active processing and less retained data could reduce energy per useful answer, particularly where memory and battery capacity are constrained. We did not measure power or joules here, and a 31× latency improvement does not imply 31× lower energy. Idle power, radio activity, synchronization and the rate of incoming work all matter.
The next energy comparison should count the complete job, including background work and synchronization. On a watch-and-phone workload, that means measuring both devices so a saving on one cannot hide extra consumption on the other. Reduced transfers could also matter more than query speed, but that remains a separate test.
Durability deserves its own comparison too: the same acknowledged-write guarantee, recovery after failure, and time until the recovered data is queryable. This campaign selected memory-resident paths on both engines. Its speed and memory results belong to that operating mode; they do not characterize either engine's durable mode. No SSD-wear saving was measured.
These measurements suggest a useful choice between execution layouts. They do not yet establish that 8DB’s automatic settings select the best route for every workload. The worker counts and pruning policy here were explicitly selected and tested.
Where this places us
8DB has a strong measured lead over SurrealDB for this combined shipping question. The size of that lead depends on the work: simple two-hop ownership lookup was much closer, at roughly 0.84 ms versus 1.15 ms in the prepared-route service. The largest advantage appeared when the query combined relationships with many temporal observations and a sequence condition.
| Alternative | Why it belongs in the comparison | Evidence for this complete shipping query |
|---|---|---|
| 8DB | Native graph composition, prepared ranges and typed time series | Measured on both execution routes |
| SurrealDB | Integrated records, relationships, time-series ranges and embedded options | Measured and tuned; the direct comparator here |
| Neo4j | Established graph querying and relationship traversal | No matched performance run in this campaign |
| PostgreSQL | SQL joins, recursive queries and window functions | No matched performance run in this campaign |
| ArangoDB | Integrated graph and document querying | No matched performance run in this campaign |
Capability references: SurrealDB deployment models, Neo4j Cypher, PostgreSQL window functions, ArangoDB features. Unmeasured alternatives are not assigned estimated speeds or a fabricated ranking.
For applications that repeatedly connect ownership, observations and conditions, this is an encouraging result. The opportunity is faster answers inside one integrated data layer. Whether that also reduces total operating cost, energy or data movement depends on the deployed workflow and deserves its own measurement.
Beyond this query
8DB is an omnimodal database. This test connects several native capabilities; it is one example of the broader system. Our time-series ingestion comparison and key-value benchmark examine different workloads and completion boundaries.
The earlier Nightmare campaign recorded 0.623 ms of in-process query execution over a prepared synthetic corpus of 87.6 million readings, of which 74,400 were selected. That remains a historical result. The new comparison uses a smaller corpus, a different workstation and a complete HTTP/JSON request boundary, so the two timings should not be treated as a regression or a like-for-like progression.
The next tests will expand the corpus and query mix, then measure durable, governed and disconnected-operation workflows. This campaign already gives us a concrete answer to the first competitive question: 8DB can combine these data types into an exact operational answer substantially faster than the tuned SurrealDB path we tested.
Bring us a question that crosses relationships, time and observations. We’ll help identify what a fair complete-answer benchmark should measure.
Method note: September 18, 2026; AMD Ryzen 9 9950X3D host, WSL Ubuntu 24.04, four allowed logical CPUs per server. Pinned SurrealDB 3.2.4 release and fingerprinted 8DB release library. No claim of general GIS superiority, universal database leadership, measured energy savings or power-loss-safe completion follows from this memory-resident test.
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