top of page

Benchmark: Trovares xGT and Neo4j™

We are always testing our graph software internally to make sure we hold our lead in performance and scalability over our competition. Below are our most recent results from benchmarking vs. Neo4j (Feb 2023).

Breadth-first-tree.svg.png

Breadth-First Search

Breadth-first search (BFS) is an algorithm for searching a tree data structure or graph for a node that satisfies a given property. It starts at the tree root and explores all of the nodes at its depth before moving to the nodes at the next level of depth. For example, in a chess endgame a chess engine might build the game tree for the current position by applying all possible moves, and use BFS to find the fastest checkmate for either side.

BFS is the backbone of graph analytics, with many other algorithms making use of it. Speedy graph traversal is key when attempting to find any valuable information in your graph, and if your graph is very large scale, the time of your graph traversal can make or break your mission critical use case. 

Neo4j GDS Benchmarks Using BFS Algorithm 

GDS is Neo4j's solution for scaling their analytics workloads. We ran benchmarks against one of the GDS algorithms, BFS. Below we show results from three different EC2 sizes on AWS: 64 virtual CPUs, 96 virtual CPUs, and 128 virtual CPUs. We ran at least three trials for each benchmark and show the average in our results. 

Screen Shot 2022-08-30 at 1.46.12 PM.png

The numbers shown represent the number of times faster xGT ran this query than Neo4j, not the number of seconds. 

As you can see, based on the results, the difference in performance between Neo4j's GDS and Trovares xGT grows with the size of the graph. While running a minor query with only 10 million edges, Neo4j might satisfy your business needs. However, when working with a graph of a more serious scale, Neo4j falters, and Trovares continues to scale linearly. With Neo4j, you could wait days for your query to return a solution. If your use case is mission-critical, fast query response time could make all the difference. 

Also worth noting, when the size of the machine we were running on increased, our performance compared to Neo4j increased as well. This is due to our ability to optimize a machine's cores to run on a single query. This makes us extremely valuable as a scalable solution for the enterprise and allows us to handle graphs with 100's of Billions of Edges in real time, the only graph solution that can.

bottom of page