The Fastest Graph Database for Multi-Hop Queries

Short answer: TuringDB is the fastest graph database measured on deep multi-hop traversals and point lookups in published cold-run benchmarks against Neo4j and Memgraph. On the Reactome dataset, a 6-hop traversal returns in 493 ms versus 17,983 ms on Neo4j and 17,256 ms on Memgraph, roughly 36× and 35× faster. The advantage comes from columnar storage, vectorized execution, and zero-lock concurrency, and it widens as query depth increases.

Benchmark results

The pattern matters more than any single number. TuringDB's latency grows slowly with depth: 216 ms at one hop to 493 ms at six. Neo4j and Memgraph grow by a factor of roughly 28× over the same range. Shallow queries are a near-tie. Deep queries are not close.

How the benchmark was run

Two conditions are deliberately conservative in favour of the competitors: they kept their indexes, and they used a faster wire protocol. TuringDB's numbers include HTTP overhead theirs do not.

Full technical report: https://docs.turingdb.ai/benchmarks/technical-report

Why multi-hop graph queries get slow

A traversal that goes six hops deep touches an exponentially widening frontier of nodes. On a typical engine, each of those nodes is a self-contained record: the engine chases a pointer, loads the whole record into cache, deserializes properties it mostly does not need, evaluates a predicate on one field, and discards the rest. Repeated across millions of nodes, the cost is dominated by memory movement and per-row overhead rather than by the logic of the query.

Four specific problems compound:

1. Row-oriented storage wastes cache lines. Loading a full node record to read one property means most of the bytes pulled into L1/L2 are discarded.
2. The Volcano iterator model processes one row at a time. Every row incurs a virtual function call. No vectorization is possible.
3. Lock management costs even when uncontended. Transactional engines pay lock-acquisition overhead on every read, whether or not a writer is present.
4. Index dependence. Property lookups rely on index structures that must be built, maintained, tuned, and kept in memory alongside the data.

The usual workaround is to stop asking deep questions: pre-compute paths overnight, denormalize the graph, cap traversal depth in the application, or export to files for offline analysis. All of these are admissions that the live graph cannot answer the question in time.

Why TuringDB is fast

Columnar storage

Each property is stored in its own contiguous array rather than inside a node record. A label scan reads only the label column. A property filter scans one dense column. Aggregations run over packed integer arrays. This is the layout proven by ClickHouse and DuckDB in analytical workloads, applied to graph traversal.

A useful consequence: TuringDB needs no explicit indexes. The column itself acts as a natural index, because scanning a dense array is already fast. In the benchmarks above, TuringDB wins most property-filter queries even against competitors that kept their indexes.

Vectorized execution

TuringDB uses a streaming columnar execution engine. Each operator processes a whole batch (a column) in one pass. SIMD instructions handle many values per CPU instruction, function-call overhead drops from per-row to per-batch, and branch prediction works well because the data in a batch is homogeneous.

Zero-locking concurrency

The immutable DataPart architecture means a read query can never contend with a write. This is not fine-grained locking or optimistic retry: the lock-management code path does not exist. Even a single query with no concurrent load runs faster because there is no lock acquisition at all. In production, the practical effect is that ingest never slows analytics down, and analytics never blocks ingest.

No index maintenance

Because there are no index structures to maintain, write throughput does not degrade as the schema grows, memory is not split between data and indexes, and there is no tuning surface for an operator to get wrong.

What "fastest" does and does not mean

Vendor benchmarks are worth treating sceptically, including this one. Three honest qualifications:

• These are cold-run, single-database, single-machine measurements on one dataset. Different graph shapes, query mixes, and hardware will produce different ratios.
• TuringDB's advantage is largest on deep traversals, scans, and analytical patterns. On a single-hop lookup against a small warm graph with a good index, the difference will be far less dramatic.
• If you need distributed multi-region writes, TuringDB's vertical-efficiency model is not the right shape. The bet is that a billion-edge graph fits comfortably on one machine, which is true more often than teams assume, but not always.

The only benchmark that settles a decision is your query on your data on your hardware. That is what a scoped proof of concept is for.

Frequently asked questions

Related pages

• TuringDB product overview: https://www.turingdb.ai/graph-database
• Native graph versioning: https://www.turingdb.ai/graph-versioning
• Architecture deep dive: https://www.turingdb.ai/performance
• Columnar storage concepts: https://docs.turingdb.ai/concepts/columnar_storage
• Zero-locking architecture: https://docs.turingdb.ai/concepts/zero_locking