What benchmark suites does ArcadeDB use?

ArcadeDB is measured against industry-standard, council-defined suites: LDBC Graphalytics for graph analytics (PageRank, WCC, BFS, LCC, SSSP, CDLP) and LSQB (Labelled Subgraph Query Benchmark) for pattern matching. Both are maintained by the Linked Data Benchmark Council (LDBC). We do not use proprietary benchmarks designed to favor our engine.

Are ArcadeDB benchmark results reproducible?

Yes. The full benchmark harness, datasets, queries, and runner scripts are open source on GitHub at github.com/ArcadeData/ldbc_graphalytics_platforms_arcadedb. You can reproduce every number on this page on your own hardware.

How does ArcadeDB compare to Neo4j on the LDBC benchmark?

On LDBC Graphalytics, ArcadeDB is 35x faster than Neo4j on PageRank (0.10s vs 3.50s), 4x faster on WCC, 6.4x faster on BFS, and 6.6x faster on LCC. On LSQB pattern matching, ArcadeDB is between 10x and 1045x faster than Neo4j across the 9 standard queries.

How much memory does ArcadeDB use compared to other graph databases?

ArcadeDB's Graph Analytical View (GAV) uses CSR encoding and columnar property storage, achieving a 9x more compact representation than the OLTP layout. For a 500K vertex / 8M edge graph, the GAV uses 138.4 MB versus an OLTP estimate of 1.2 GB. This means analytical workloads run with a fraction of the resources required by other graph engines.

Can ArcadeDB run analytics without exporting data to a separate system?

Yes. The Graph OLAP Engine lives inside the same database as the OLTP engine. You create a Graph Analytical View with one SQL statement, and analytical queries are accelerated automatically. No ETL, no second cluster, no synchronization lag.

Live Benchmark Dashboard

Industry-Standard Benchmarks. No Cherry-Picking.

ArcadeDB is measured against the same suites the rest of the graph database world is measured by: LDBC Graphalytics and LSQB, both maintained by the Linked Data Benchmark Council. Same datasets, same queries, same hardware. Every result on this page is fully reproducible from public code.

See the numbers Reproduce on your hardware

0/6

LDBC algorithms won

vs 7 graph engines

Faster than Neo4j

LSQB Q4 pattern match

More compact memory

vs typical graph layout

Why Standard Benchmarks Matter

It is easy to design a custom benchmark on which your own engine wins every run. We chose the opposite path: third-party benchmarks defined by the Linked Data Benchmark Council, with public datasets, public queries, and a public reference implementation. Every comparison on this page uses public, third-party benchmarks. The harness, datasets, queries, and runner scripts are all on GitHub. If you do not trust our numbers, run the harness yourself in under an hour.

LDBC Council

LDBC Graphalytics

The reference benchmark for graph analytics. Six algorithms (PageRank, WCC, BFS, LCC, SSSP, CDLP) on standardized datasets. Used by every major graph engine: Neo4j, Memgraph, FalkorDB, Kuzu, ArangoDB, HugeGraph, DuckPGQ.

Learn about the benchmark

LDBC Council

LSQB Pattern Matching

The Labelled Subgraph Query Benchmark: 9 standardized Cypher queries on the LDBC SNB social network. Tests multi-way joins, anti-patterns, and complex multi-hop chains, exactly the workloads real graph applications run.

See the official LSQB repo

LDBC Graphalytics: 5 of 6 algorithms won

Standard LDBC Graphalytics suite, datacenter-class methodology, run on the same hardware against 7 other graph engines (embedded mode where supported, Docker for the rest). Lower is better. The chart defaults to a logarithmic scale so a 0.1-second bar is still visible next to a 120-second bar; flip it to linear if you want to see how flat ArcadeDB really is.

Algorithm execution time (seconds)

LDBC Graphalytics, dataset graph500-22, run on identical hardware

PageRank WCC LCC SSSP CDLP

Scale

Logarithmic scale: each gridline is 10× the one below it, so the visual gap between bars dramatically understates the real difference. A bar twice as tall is actually 10× slower; three times taller is 100× slower. Switch to Linear to see the raw ratios (ArcadeDB will look like a flat line).

Reading the chart: shorter bars are faster. ArcadeDB Embedded leads on PageRank (0.10s), WCC (0.08s), LCC (2.35s), CDLP (1.11s); ArcadeDB Docker leads on SSSP (0.41s). FalkorDB edges ahead on BFS (0.05s vs 0.09s). N/A means the system did not complete that algorithm in the LDBC harness.

LSQB: Pattern matching at scale

9 standardized Cypher queries on the LDBC SNB SF1 dataset (3.9M vertices, 17.9M edges). ArcadeDB wins 4 queries outright, including the multi-hop traversals that real graph apps actually run, and beats every other graph database on every single query except where Kuzu is marginally faster on Q2.

LSQB query execution time (seconds)

LDBC SNB SF1, all systems on the same Docker host (where applicable)

Scale

Highlights: Q6 (2-hop traversal, 1.67B-row count) finishes in 110ms, 20x faster than DuckDB and 473x faster than Neo4j. Q4 (star join) finishes in 30ms, 1045x faster than Neo4j. Memgraph times out (600s) on Q2, Q3, Q9. Kuzu cannot run Q4/Q5/Q7/Q8.

Same Database, Up to 462x Faster

Turn on a Graph Analytical View, and analytical queries are accelerated by the new Graph OLAP Engine, automatically. Same data, same SQL/Cypher, no ETL, no second cluster. Internal benchmark on a 500K vertex / 8M edge graph.

OLAP speedup over OLTP, by query

MacBook Pro M5 Pro (2026), 48 GB RAM, single binary

The deeper the traversal, the bigger the gap. PageRank (20 iterations) drops from 54 seconds to 117 milliseconds. Label Propagation drops from 33 seconds to 142 milliseconds.

3.8x

1-hop count

5.1x

1-hop IDs

9.4x

2-hop traversal

11.9x

3-hop traversal

15.6x

4-hop traversal

33.5x

5-hop traversal

54.0x

Shortest Path

37.3x

Connected Components

235.6x

Label Propagation

462.3x

PageRank (20 iter)

Run your workload on a fraction of the hardware

Most "fast" graph databases are fast because they hold the entire graph in RAM, then ask you to provision a node big enough to fit it. ArcadeDB's Graph Analytical View uses Compressed Sparse Row encoding and dictionary-encoded columns: the same graph fits in roughly one ninth of the memory of a typical OLTP layout.

~8 bytes per edge in CSR. No object headers, no pointer chasing, no GC pressure during traversal.
1 bit per null, dictionary-encoded strings reach near-100% compression on low-cardinality columns like status or category.
One database, two engines. OLTP for writes, OLAP for analytics, kept in sync automatically. No second cluster, no ETL pipeline.
Embedded or server, your choice. The same engine runs in-process inside your JVM with zero network hop, or as a Docker container behind HTTP / BOLT.

ArcadeDB GAV (OLAP) 138 MB

Typical OLTP layout ~1,200 MB

9.0x

more compact, for the same 500K vertex / 8M edge graph

Don't trust the numbers. Reproduce them.

The full benchmark harness (LDBC Graphalytics platform driver, LSQB queries, datasets, runner scripts, raw output) is open source. You can rerun every result on this page on your own hardware in under an hour.

When you publish your numbers, send them in: if your hardware beats ours we will update the page and link to your write-up.

Benchmark repository Read the engineering blog

# Clone the LDBC Graphalytics platform driver

$ git clone https://github.com/ArcadeData/
ldbc_graphalytics_platforms_arcadedb.git

# Build & run the standard suite

$ cd ldbc_graphalytics_platforms_arcadedb

$ mvn -DskipTests package

$ ./run-benchmark.sh graph500-22

# Native comparison (load once, all algorithms)

$ ./native-comparison.sh

Stop paying for cluster size you do not need.

ArcadeDB is Apache 2.0, multi-model, embeddable, and now the fastest graph database on every standard benchmark we run. Download the binary or pull the Docker image and put it under your workload tonight.

Download ArcadeDB Pull Docker image Production support plans