218,000 lookups per second for 8DB. A best recorded 3,410 for Neo4j. Both on an M1 laptop. A separate one-hop test also put 8DB ahead, reaching 23,300 queries per second.
These are recorded service results for simplified person and five-friend queries, with different client stacks. The larger buying question is how much useful graph work an omnimodal engine can do while retaining the surrounding data and evidence.
Record lookup and one-hop traversal
8DB finished ahead of Neo4j in both recorded service comparisons. Five-neighbor retrieval delivered 5.6× Neo4j’s strongest reported throughput; basic record lookup delivered 64× its best eight-worker result. That puts 8DB first of the two tested systems on these operations.
Open full-size competitive standing chart · Read the comparison contracts
These are measured service configurations on the same M1, including their different clients and returned-data contracts. The neighbor result is preserved in a campaign report; the lookup result also has its original log. The sections below explain both comparisons.
Our market assessment: a strong performance challenger on the operations tested. The broader opportunity is fast graph access inside an omnimodal engine that can also retain spatial structure, documents, signals and evidence. An overall graph-database rank remains open: complex queries, updates and scale require a shared workload. The other vendors’ full-suite scores stay in the supporting market context below.
Graph data, geometry and deployment
8DB’s case is the combination: native participant roles, richer geometry and an engine that can run with the application. The matrix compares those requirements with a graph incumbent and three alternatives that overlap with our broader architecture.
Open full-size capability comparison
Read the comparison as a text table
| Requirement | 8DB | Neo4j | ArangoDB | SurrealDB | TypeDB |
|---|---|---|---|---|---|
| Connect a group | Native n-ary facts + roles | Pairwise edges; model group nodes | Two-endpoint edge documents | Two-endpoint edges + record links | Native n-ary relations + roles |
| Work with geometry | n-D distances; point clouds; manifold paths | 2-D/3-D points; distance + bounding boxes | GeoJSON shapes; n-D numeric range indexes | GeoJSON points, lines + polygons | Native spatial operators not verified here |
| Keep other data | Records, documents, vectors + time series | Graph properties + vector indexes | Documents, graph + vector indexes | Documents, graph + vector indexes | Entities, relations + typed attributes |
| Run the engine | In-process engine + mesh APIs* | Java/JVM embedding or server | Server or cluster | In-process engine or server | Server or cloud |
A relationship involving an asset, sensor, observation and operator can remain one role-aware fact in 8DB. Its location and measured geometry can stay alongside it. That could reduce the modelling and integration work needed for a local decision. The advantage to evaluate is that complete combination; the graph timing above measures only two of its service operations.
The alternatives overlap in meaningful ways. TypeDB also has native multi-party roles. SurrealDB also embeds its engine. ArangoDB combines graph, document and vector access, and its numeric multidimensional indexes go beyond its GeoJSON path. Neo4j offers Java embedding and indexed 2-D/3-D points. Our broader geometry paths and mesh integration create additional options, with actual footprint, speed and recovery assessed for the chosen deployment.
Chart basis: selected current documented capabilities, separate from the historical benchmark. Native spatial operators were not verified for TypeDB in this review; that is not an absence claim. For 8DB, protected-node qualification currently has a narrower canonical-lexical record profile than the full modality catalogue.
Sources: 8DB structures and deployment scope; Neo4j spatial operators and Java embedding; ArangoDB edge model, spatial indexing, multidimensional ranges and deployment; SurrealDB relations, geometry and embedding; TypeDB relations and roles and deployment.
The lookup result, in context
The September 8 campaign ran on a MacBook Pro with an Apple M1, four performance cores, four efficiency cores and 16 GB of RAM. Both lookup setups contained one million records. Neo4j 2026.07.1 had an online person-ID index, a warm JVM, a 2 GB heap and a 1 GB page cache. 8DB used its tree engine through MVCC read snapshots, with an in-memory storage backend.
Across three interleaved rounds, 8DB recorded 209,000–223,000 single-request reads per second. Its median was 218,000. Neo4j’s strongest eight-worker round recorded 3,410 queries per second. Dividing those two values gives 63.9×, rounded to 64× in the headline. The comparison deliberately uses Neo4j’s best round, rather than its slower first round. Campaign report · Original sweep log
| What the client requested | 8DB | Neo4j |
|---|---|---|
| Lookup | Eight-byte key to a 100-byte value | Indexed person ID to three properties |
| Client and connection | Rust client, local Unix socket | Python driver, Bolt |
| Request discipline | Eight workers, one request in flight per connection | Eight workers, one request in flight per connection |
| Recorded throughput, three rounds | 218,000; 209,000; 223,000 reads/s | 991; 3,410; 3,325 queries/s |
| Result checking | Every returned value checked by the client | Returned properties checked by the client |
The logs report zero incorrect results in these rounds. Background work was active on the laptop, and Neo4j improved as the campaign progressed. The ratio therefore describes this recorded setup, including client, query processing and transport costs. It does not establish that 8DB performs an identical property query 64× faster inside the engine.
These were resident read tests. They do not measure durable ingestion or crash recovery. The in-memory setting belongs to this benchmark configuration; it is not a statement that 8DB lacks durable storage.
Following relationships: 23,300 queries a second
A point lookup is only the beginning of graph work. The next test asked for five outgoing friends of a person across one million persons and five million directed relationships.
8DB encoded each relationship with a person-and-friend key and retrieved a person’s neighbors through a snapshot range scan. The client checked the exact five keys and their values. The Neo4j campaign checked the returned friend IDs. This is a useful graph primitive: retrieving the immediate relationships that an application needs before deciding what to inspect next.
| September one-hop test | Recorded queries/s | Comparison with 8DB |
|---|---|---|
| 8DB, eight workers | 23,300 median | Reference result |
| Neo4j, eight workers | 2,001 median | 11.6× as many queries/s for 8DB |
| Neo4j, four processes × eight connections | 4,134 best reported round | 5.6× as many queries/s for 8DB |
The retained report records three rounds and successful result checks. Its original traversal log was lost in a reboot, so this figure has weaker archival support than the lookup result. The query also returns fewer properties than official LDBC IS-3 and does not order friendships by creation date. It measures the simplified outgoing-neighbor service, using 8DB’s Rust/local-socket path and Neo4j’s Python/Bolt path. Traversal report
For customer records, asset dependencies or a recommendation candidate set, fast immediate-neighbor retrieval is useful in its own right. Deep traversal, skewed high-degree graphs and concurrent updates are separate questions.
Where does that put 8DB in the market?
The recorded wins place 8DB ahead in this two-system campaign. The next comparison is the complete application: complex traversals, updates, scale and the surrounding data operations. The wider market includes products competing on distributed graph analytics, query languages, managed operation and combinations of graph with other data models.
For another view of the competitive bar, the Graph Data Council publishes audited full SNB Interactive results. Selected SF100 entries show the scale of those campaigns:
| Published system and audit date | Full-workload operations/s at SF100 | Reported server resources |
|---|---|---|
| Huawei GES, December 2025 | 129,090 | 160 Kunpeng cores; 1,280 GiB RAM; driver on the same machine |
| GraphScope Flex, April 2025 | 79,244 | 96 EPYC cores / 192 threads; 768 GB RAM; separate driver machine |
| TuGraph, January 2023 | 16,966 | 64 YiTian cores; 256 GiB RAM; separate driver machine |
These are market reference scores, not a speed ranking against our laptop. Full SNB Interactive mixes more complex queries and updates on a different generated graph. A simple lookup and a full-workload operation are different units of completed work, even when both are counted per second. The server specifications provide context; dividing by core count would not make the workloads equivalent. Dates and configurations also differ between the reference entries. Audited results · Huawei disclosure · GraphScope disclosure · TuGraph disclosure
What changed as we optimized?
The recovered history contains several different campaigns, not one interchangeable series of scores.
May’s EC2 test recorded 296,610 lookups/s inside the benchmark server. A May 11 local 7950X experiment later recorded 543,567 lookups/s as the median of three post-change runs, against a single earlier result of 428,042 on that machine. Those are useful development measurements. They do not include one client round trip for every lookup.
September moved to client-driven tree-engine reads: 96,000/s median in the first sweep, then 218,000/s median after the per-request path adopted the existing value visitor and the client used local sockets. The code change avoids an intermediate value allocation; transport and host load also changed, so the entire increase cannot be assigned to that one optimization. First September sweep · May local A/B record
Batching offers another practical option. The September optimized log recorded 2.01 million reads/s median with batches of 128. That mode amortizes request and snapshot work. It is relevant when an application can group independent lookups, but it does not replace the single-request comparison or predict the latency of an individual interactive request.
There is a useful next challenge on both sides. Neo4j documents a Rust extension for its Python driver and different transaction patterns that can improve throughput. Testing those alongside 8DB’s configuration choices would show how much advantage remains with equally optimized clients. This campaign did not establish Neo4j’s universal performance ceiling. Neo4j tuning guidance
What 8DB offers beyond a faster lookup
The bigger opportunity is doing more of the application’s job with the data already connected. Three practical differences deserve attention.
| Decision | 8DB’s proposition | Neo4j’s actual alternative | Why it could matter |
|---|---|---|---|
| Richer structure | Native n-ary roles, n-dimensional coordinate operations, point clouds, lattices and multiscale representations | Property graph modelling; native spatial points and indexes; specialist operations may require additional modelling or integration | Preserve the structure a scientific or operational question needs. |
| Deployment near the data | An embeddable engine with device-aware settings and native mesh coordination; published platform scope includes iOS and watchOS | Java embedding requires a JVM. Documented engine platforms are desktop/server systems, not iOS/watchOS | Local decisions and controlled exchange can be relevant where a separate server or reliable connection is impractical. |
| Evidence and governed exchange | Source-linked views, uncertainty, policy and supported protected-node delivery in the data architecture | Model provenance in the graph and combine it with Neo4j’s access controls and surrounding services | Reduce the application work needed to keep a result connected to its evidence and permitted use. |
These are architectural differences, not savings measured by this lookup campaign. 8DB structures and scope, deployment and evidence, protected-node boundaries.
“Embedded” and “spatial” need more than a checkmark
Neo4j can be embedded in a Java application. Its current engine requires a compatible JVM; its published supported-platform list covers desktop and server operating systems. That is a different deployment proposition from an engine integrated into a phone or watch app. The 2 GB minimum in Neo4j’s development guidance is a system recommendation, not a measured embedded footprint. Our M1 results likewise do not establish watch memory or battery use. Java embedding · System requirements
Neo4j’s native spatial path works with 2-D/3-D points, with indexes optimized for distance and bounding-box predicates. 8DB’s documented paths extend to n-dimensional coordinates, point-cloud neighborhoods and declared manifold geometry. That is a useful difference in operation breadth. This campaign did not compare the two systems’ spatial speed, and the extra operations should be evaluated on the intended data and metric. Neo4j spatial values · Point-index predicates
Neo4j also has vector search, fine-grained access control and a substantial graph-analysis toolkit. Those are real competing capabilities. TypeDB’s native multi-party relations and ArangoDB/SurrealDB’s integrated models further raise the bar: our case rests on the useful combination and its implementation, not an exclusive claim to every ingredient. Vector search · Access control · Graph Data Science
For example, a field inspection can connect an asset, its measured shape, changing telemetry, a technician’s report and the rules for sharing it. Keeping those views together could reduce reconciliation and improve time to an informed decision. The next useful test is that complete workflow, including resource use and recovery, against an integrated alternative as well as a graph specialist.
The performance series already covers key-value reads, time-series ingestion, analytical queries and spatial search. Each tests a different part of the same product; their peak rates are not additive.
Have a graph query that determines a real decision? Bring us the query. We can identify the useful comparison: the returned facts, dataset, latency target and operating guarantees, then test whether 8DB can deliver the result while keeping the surrounding context in the same system.
Evidence note: This is a historical engineering comparison, not an audited LDBC submission. The person and friendship datasets are custom deterministic fixtures. Official IS-1 and IS-3 have fuller result contracts. The packet retains reports, the two recovered lookup logs, source revisions, calculations and open replication tasks. Exact historical binaries and the Neo4j client scripts were not recovered. No new benchmark runs were performed for this article.
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