Why and How to Choose a Graph Database: Benchmarking for Knowledge Graph and Financial Applications

Graph databases are the core of knowledge‑graph systems; the choice of a graph database determines the system's scale, performance, and stability, making selection a critical decision.

There are many graph‑DB types, such as Neo4j, JanusGraph, and Ant Group's TuGraph, each differing in query languages (Cypher, Gremlin), data models (property graph vs. RDF), and features like permissions, multi‑graph support, and hypergraph capabilities.

Because graph databases lack a unified standard like SQL, users often face confusion when selecting a product, especially when use cases are exploratory and the required algorithms and features are unknown in advance.

Benchmark programs are essential tools for graph‑DB selection; they simulate real‑world scenarios to evaluate functionality, performance, and stability, similar to how TPC‑C benchmarks relational databases.

A good benchmark must be realistic, meet latency requirements, be scalable to various data sizes (from GB to TB), and adhere to strict, auditable standards that validate data and results.

Existing graph benchmarks such as the Twitter dataset have serious drawbacks: limited scalability, lack of write operations, and insufficient realism for many domains.

Some vendors add custom tests focusing on read‑write mixes, but these often lack extensibility and rigorous standards, limiting their usefulness as reference benchmarks.

The most widely accepted graph‑DB benchmark is LDBC's SNB, which models a social‑network workload with scalable data sizes, mixed read‑write operations, strict latency limits, and comprehensive correctness checks.

Financial graph workloads differ from social graphs: they have smaller out‑degrees, many multi‑edges (e.g., frequent transfers between accounts), higher latency demands, and often combine reads and writes in a single query, requiring features like TTL and load‑peak handling.

Ant Group is designing a financial‑graph benchmark in collaboration with LDBC, focusing on online queries with strict latency, variable load patterns, data expiration, and anti‑fraud scenarios; an example mixed read‑write query is illustrated in the accompanying diagram.

In conclusion, selecting the right graph database is vital for graph‑based applications, and a well‑designed benchmark can become a de‑facto standard that guides system design and promotes industry standardization.