Dataset Overview

The LDBC Social Network Benchmark (SNB) is the reference benchmark of the Linked Data Benchmark Council for graph data management systems. Unlike the other datasets in PropGBench, which are real-world data, SNB is generated: its data generator simulates a Facebook-style social network over a fixed timeline, so the graph can be produced at any scale factor while keeping its structural properties — a power-law degree distribution, realistic clustering, and correlations between where people live, what they are interested in, and whom they know. PropGBench uses the Business Intelligence (BI) workload at scale factor 100. More

The graph has two halves. The static part is real-world reference data scraped from DBpedia — 1,460 places, 7,955 universities and companies, and a 16,080-tag hierarchy — and never changes. The dynamic part is the simulated social activity: people registering, befriending each other, joining forums, and posting and replying. Every dynamic entity carries a creationDate, and the generator emits a continuous timeline that is cut at one instant. Everything before the cut is the initial snapshot; everything after it is delivered as separate insert and delete streams.

PropGBench loads only the initial snapshot, whose latest creationDate is 2012-11-29T02:52:42.849+00:00. The insert and delete streams that ship with the dataset are not applied, because the BI queries measured here are read-only. The graph under test is therefore a fixed, reproducible snapshot rather than a moving target.

Total node count: 254,634,696

Total edge count: 1,703,042,944

Dataset Download

LDBC publishes pre-generated data sets, so the generator does not need to be run. PropGBench uses scale factor 100 in the composite-projected-fk serialisation, in which every entity and every relationship is its own directory of pipe-delimited CSV shards. The download is 29.3 GiB compressed and expands to roughly 115 GB.

The archive is Zstandard-compressed and can be decompressed while it downloads, which avoids ever storing the compressed copy:

curl --silent --fail https://datasets.ldbcouncil.org/bi-pre-audit/bi-sf100-composite-projected-fk.tar.zst \
  | tar -xv --use-compress-program=unzstd

Two things about the CSV files are worth knowing before loading them. They carry no header row — the column definitions live in a separate tree of header files, which the reference implementations provide per system. And some of the generator's output shards are legitimately empty, so a loader must tolerate empty files rather than treat them as an error.

The query parameters are generated per scale factor and are not interchangeable between scale factors. For SF100, note that the 15a and 20a parameter files are empty and 15b holds only four parameter sets, so Q15 has far fewer runs available than the other queries.

Benchmark Workloads

Select a platform below to view the specific data loading commands and queries used to benchmark performance.

A PuppyGraph implementation for this dataset is not available yet.

The BI workload defines 20 queries. Three of them (Q15, Q19, Q20) are weighted shortest-path queries whose edge weights are derived from interaction history, and one (Q10) isolates the ring of people at a given friendship distance, so systems without a graph-algorithm library or recursive traversal need their own implementations of these four.

Runtime Results

* The unit of all results shown below are in milliseconds (ms): the client-side wall-clock time of one run. Neo4j ran with a two-hour limit per query; TigerGraph and GraphFrames ran with a one-hour limit, and no query reached it. — means not measured yet.

* MEMORY_LIMIT means the query ran out of memory (Neo4j heap of 10 GiB, a TigerGraph node falling below its critical free-memory level, or a Spark executor/driver out of memory); TIMEOUT means the query ran for more than two hours without finishing; NOT SUPPORTED means the database platform does not support certain features required by the query; POOL LIMIT means the intermediate results generated by the query exceeded the engine-configured memory pool limit (Neo4j’s 8 GiB transaction memory pool); FAILED means the system reported another error.

* Neo4j: all 41 queries have been run. Q10–Q12, Q20, Q22 and Q27–Q41 were run with a two-hour limit per query; the others finished within the earlier one-hour limit. The GDS graph projections of Q11, Q12 and Q27–Q31 are built before the query and not timed; Q11’s projection did not finish within its 20-minute limit and Q12’s exceeded the transaction memory pool, so neither query could run.

* GraphFrames: all 41 queries have been run. Q30 is not supported: GraphFrames’ only strongly connected components implementation (GraphX) cannot process the directed KNOWS graph, a deep acyclic graph; Q31 runs Label Propagation in place of Louvain, which GraphFrames does not provide.

* TigerGraph: all 41 queries have been run on the six-node cluster, which also keeps the other graphs loaded in memory.

* PuppyGraph: query runs are pending.

Memory Results

* The unit of all memory results shown below is megabytes (MB, 10⁶ bytes). Each platform reports a different kind of peak, so the columns show where a query is heavy within one platform and should not be compared across platforms.

* Neo4j: the query’s peak memory from PROFILE (operator memory, not the JVM heap or page cache). It does not include the GDS graph projection that Q27–Q31 read: 114.5 MB for the undirected KNOWS graph and 77.6 MB for the directed one used by Q30.

* TigerGraph: the sum over the six GPEs of each GPE’s peak vertex-accumulator memory for the whole query, from the query profile. The peaks need not occur at the same time, and the value is not process memory.

* GraphFrames: the largest peak execution memory of a single Spark task of the query; not the executors’ total or process memory.

* Failed queries show the same status as in the runtime table.

Loading the SF100 snapshot into Neo4j Enterprise 2026.05.0 with neo4j-admin database import full took 3,967 seconds (1h 6m 7s) and produced a 201 GB store, with all uniqueness constraints and secondary indices built during the import.

Loading the same snapshot into TigerGraph Enterprise 4.2.4, on a six-node cluster, took 1,061.5 seconds (17m 42s): 1,011.7 seconds for the four loading jobs, 13.9 seconds to merge the loaded deltas and 36.0 seconds to build the secondary indices.

For GraphFrames, Spark read the same CSV files and wrote one Delta table per node and edge type to HDFS in 379.0 seconds (6m 19s), producing 41.9 GB of Delta tables (125.6 GB on HDFS with 3-way replication). The graph itself is built from those tables when a query runs.

Every node and relationship count matches across the three loads. The three figures are not a like-for-like comparison: Neo4j ran on a single machine, while TigerGraph and Spark each used six worker nodes.