Lane
Graphs
Interactive and analytical queries on a social network graph.
Results
Tasks and results.
The tasks come from the Linked Data Benchmark Council's Social Network Benchmark. The interactive half reads a graph at several depths: a point lookup, one hop, two hops, and a three-hop read with a property filter. It also inserts, updates and deletes.
The analytical half asks questions that touch the whole graph, such as the degree distribution and the triangle count. A triangle count returns one small number, so it is a strong answer check: if two engines disagree on it, one of them is wrong.
Each engine is asked in the language it is normally asked in. A query that exceeds its time budget is published as censored, with its budget, and is never dropped.
Graph interactive queries: point lookup, one hop, two hops, and a three-hop read with a property filter, with insert, update, and delete beside them. Warm medians, with the ninety-ninth percentile on the point lookup.
| Engine | Mode | Size | point p50 ms ↓ | point p99 ms ↓ | 1-hop p50 ms ↓ | 2-hop p50 ms ↓ | 3-hop filtered p50 ms ↓ | insert p50 ms ↓ | update p50 ms ↓ | delete p50 ms ↓ | ingest vertices+edges/s ↑ | ingest total s ↓ | peak memory GiB ↓ | disk GiB ↓ |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ArcadeDB | embedded | SF1 (10k people, 181k friendships) | 0.48 | 0.91 | 0.45 | 0.71 | 5.57 | 0.49 | 0.20 | 0.49 | 87k | 2.18 | 2.79 | 0.013 |
| ArcadeDB | server | SF1 (10k people, 181k friendships) | 1.23 | 1.84 | 1.18 | 1.47 | 6.61 | 1.26 | 0.86 | 1.07 | 25k | 7.54 | 3.36 | 0.012 |
| ArangoDB | server | SF1 (10k people, 181k friendships) | 0.72 | 0.96 | 1.00 | 2.28 | 17.0 | 0.80 | 0.68 | 0.86 | 98k | 1.94 | 0.50 | 0.048 |
| DuckPGQ | embedded | SF1 (10k people, 181k friendships) | 0.25 | 0.29 | 0.93 | 2.24 | 3.30 | 10.5 | 9.06 | 10.5 | 187k | 1.02 | 0.19 | 0.041 |
| FalkorDB | server | SF1 (10k people, 181k friendships) | 0.13 | 0.28 | 0.22 | 0.34 | 0.61 | 0.16 | 0.12 | 0.76 | 41k | 4.70 | 0.18 | 0 |
| LadybugDB | embedded | SF1 (10k people, 181k friendships) | re-run | re-run | re-run | re-run | re-run | re-run | re-run | re-run | re-run | re-run | re-run | re-run |
| Memgraph | server | SF1 (10k people, 181k friendships) | 0.15 | 0.35 | 0.15 | 0.21 | 1.17 | 0.15 | 0.14 | 0.14 | 72k | 2.66 | 0.46 | 0.024 |
| MongoDB | server | SF1 (10k people, 181k friendships) | 0.090 | 0.28 | 0.27 | 0.90 | 78.9 | 0.23 | 0.086 | 0.32 | 131k | 1.45 | 0.25 | 0.022 |
| Neo4j | server | SF1 (10k people, 181k friendships) | 6.11 | 12.7 | 5.66 | 4.66 | 6.29 | 7.14 | 5.89 | 6.06 | 37k | 5.21 | 4.74 | 0.015 |
| SurrealDB | embedded | SF1 (10k people, 181k friendships) | 0.044 | 0.051 | 0.69 | 15.2 | 190.0 | 0.18 | 0.083 | 0.15 | 14k | 13.8 | 0.80 | 0.10 |
| SurrealDB | server | SF1 (10k people, 181k friendships) | 0.11 | 0.61 | 0.17 | 0.57 | 28.8 | re-run | re-run | re-run | 20k | 9.51 | 0.31 | 0.047 |
| ArcadeDB | embedded | SF10 (66k people, 1.9M friendships) | 0.51 | 1.05 | 0.62 | 1.55 | 23.4 | 0.52 | 0.20 | 0.46 | 87k | 23 | 8.19 | 0.13 |
| ArcadeDB | server | SF10 (66k people, 1.9M friendships) | 1.13 | 1.67 | 1.30 | 2.36 | 24.9 | 1.32 | 0.83 | 1.15 | 28k | 71.9 | 7.99 | 0.14 |
| ArangoDB | server | SF10 (66k people, 1.9M friendships) | 0.90 | 1.12 | 1.06 | 6.00 | 92.4 | 0.91 | 0.74 | 0.93 | 91k | 21.9 | 0.78 | 0.41 |
| DuckPGQ | embedded | SF10 (66k people, 1.9M friendships) | 0.26 | 0.33 | 1.33 | 4.27 | 6.96 | 10.6 | 9.02 | 10.8 | 275k | 7.28 | 0.31 | 0.16 |
| FalkorDB | server | SF10 (66k people, 1.9M friendships) | 0.13 | 0.42 | 0.24 | 0.66 | 1.51 | 0.17 | 0.10 | 0.21 | 24k | 85.3 | 0.37 | 0 |
| LadybugDB | embedded | SF10 (66k people, 1.9M friendships) | re-run | re-run | re-run | re-run | re-run | re-run | re-run | re-run | re-run | re-run | re-run | re-run |
| Memgraph | server | SF10 (66k people, 1.9M friendships) | 0.15 | 0.40 | 0.15 | 0.30 | 3.71 | 0.15 | 0.14 | 0.14 | 71k | 28.1 | 0.66 | 0.24 |
| MongoDB | server | SF10 (66k people, 1.9M friendships) | 0.089 | 0.33 | 0.40 | 1.71 | 345.2 | 0.22 | 0.086 | 0.32 | 161k | 12.5 | 1.10 | 0.19 |
| Neo4j | server | SF10 (66k people, 1.9M friendships) | 7.18 | 12.3 | 7.07 | 6.23 | 13.2 | 7.54 | 6.23 | 6.45 | 44k | 45.4 | 13.1 | 0.66 |
| SurrealDB | embedded | SF10 (66k people, 1.9M friendships) | 0.047 | 0.058 | 1.38 | 60.7 | 1,217 | 0.20 | 0.089 | 0.18 | 11k | 176.2 | 5.67 | 1.09 |
| SurrealDB | server | SF10 (66k people, 1.9M friendships) | 0.17 | 0.60 | 0.40 | 1.24 | 210.5 | re-run | re-run | re-run | 18k | 111.3 | 2.14 | 0.26 |
↑ higher is better, ↓ lower is better; the best value in each column, within one size, is bold
Measured rows: benchmarks/experiments/results/runs_paper_oct.csv
Exact builds measured
- arcadedb 26.10.1-dev · 417314c18 (in-process)
- arcadedb 26.10.1-dev · 417314c18
arcadedb-c25:417314c18 - arangodb 3.12.11
arangodb@563cb2c07af0… - duckdb 1.5.4 + duckpgq f386a6c
- falkordb 4.20.6
falkordb/falkordb@0a9fe4d1ee0b… - memgraph 3.13.1
memgraph/memgraph@4710bee1ab5b… - mongodb 8.2.12
mongo@41afd6e1183f… - neo4j 2026.08.1
neo4j@e702d6b535d9… - surrealdb 2.3.10
- surrealdb 3.2.4
surrealdb/surrealdb@6a5002363ff5…
- Disk is what the workload left on disk, in GiB: the engine's writable layer plus its volumes after the cell, minus the same engine's empty footprint.
- LadybugDB's row is marked `re-run`: it sized its thread count and buffer pool from the whole machine rather than from the cores and memory its cell was given, while every other engine here that sizes itself from the machine was fitted to its cell. It is being re-measured with both fitted.
- SurrealDB (server)'s write cells are marked `re-run`: the server ran at its default, a sync to disk at every commit, although it has a setting that does not wait, and every other engine on this table that has such a setting ran at it. Our harness missed that setting, and the next measurement runs its writes at it. Its read cells commit nothing and stay.
- In this measurement every person's age loaded as zero, through a date-parsing error in our data loader, so the 3-hop filtered read (age above 30) matched no one on any engine: its times are three hops plus a check on every end node. The next measurement parses the ages correctly.
- Each friendship is one edge, pointing from the person with the smaller id to the person with the larger. The engines can follow an edge from either end, but the 1-hop, 2-hop, and 3-hop reads follow it only the way it points, so 1-hop counts only the friends with a larger id than the start person, and 2-hop and 3-hop reach only people along a chain of rising ids. The next measurement asks the same questions in both directions of a friendship.
- Each read on this table is timed twice over the same start persons, and the table prints the first pass, so its read columns include each engine's warm-up. On ArcadeDB (embedded), ArcadeDB (server), and Neo4j, which run on a JVM, that warm-up includes the JVM compiling the query path. The next measurement gives every engine an untimed warm-up on other start persons first, prints the warm median, and adds the first query of a session as the cold column.
- Durability is matched at the relaxed end: on every engine that has the setting, a commit returns without waiting for the disk and the log is flushed by the engine's own background policy, which is ArcadeDB's engine default and a documented production mode for each of the others. Each row records what it ran as `durability`, and the setting was read out of the engine rather than assumed on every engine except ArcadeDB (server) and SurrealDB (server). ArcadeDB (server) is given the setting when the server starts, and the row records it, because the server offers no way to read it back. The exceptions on this table are DuckPGQ and Neo4j, which have no setting to relax and wait for the disk at every commit; their write and transaction cells are paying for that. SurrealDB (server)'s rows record that no setting was found, and its server log shows what it ran: its default in both runs, a sync to disk at every commit (the log reads "Sync mode: every transaction commit" in every run), although it has a setting that does not wait; the next measurement runs both.
- Every engine traverses the same persons-and-KNOWS projection, with edges stored in both directions.
- ArcadeDB (embedded), ArcadeDB (server), and Neo4j run on a JVM, and for them this column is close to the heap they were given rather than the memory the work needed: Neo4j's 4.74 GiB here is about 119 per cent of its 4g heap. Every engine on a table gets the same memory envelope; how much of it a JVM takes is a property of the runtime, so read these cells against each other rather than against an engine that manages its own memory.
- Every repetition, on every engine, runs each read against the same start persons, 500 at SF1 (10k people, 181k friendships) and 200 at SF10 (66k people, 1.9M friendships), plus 1,000 each of the insert, update, and delete; the p50 and p99 are over those. The start persons are picked at random with a fixed seed and with replacement, so one person can be picked more than once.
- FalkorDB at SF1 (10k people, 181k friendships) and SF10 (66k people, 1.9M friendships): its disk cells are 0.0 because the server container did not grow over its empty footprint during the run: at the relaxed setting FalkorDB persists only by timed snapshots, with no append-only file, and none had been taken when disk was measured, so the graph was held in memory only; read them as a floor under 0.01 GiB, not as a size.
- In the cells: `re-run` means the cell was measured before a fix to our harness and stays off the table until it is measured again; the note says what was wrong. A dash is an operation the engine cannot express, never a slow one.
- Ingest paths: ArcadeDB embedded loads through the Java API (newVertex, newEdge) in 5,000-record transactions; served sends CREATE VERTEX and CREATE EDGE statements as sqlscript batches over HTTP; Neo4j and Memgraph UNWIND batches over bolt; FalkorDB the same UNWIND batches over the Redis protocol; LadybugDB COPY from CSV, its native bulk path; DuckPGQ registers each batch as an Arrow table and INSERT ... SELECTs from it into the Person and knows tables, then defines the property graph over them; ArangoDB import_bulk; MongoDB insert_many; SurrealDB inserts the persons through its Python SDK and the KNOWS edges as bulk relation inserts.
Still being measured at this version. This table appears here when its run finishes.
The rules every result follows are in the methodology. The settings for each engine are on the engines page. If one is wrong, tell us.
DBBench
The other lanes.
- Tables: Documents and structured query language (SQL) analytics.
- Vectors: Dense and sparse vector search, with recall beside every latency.
- Time series: Monitoring-style queries over timestamped readings.
- Cross-model: One operation across a vector, a graph edge, and a document.
- Lifecycle: Opening, closing, deployment boundaries, and what waiting for the disk costs.
Resources