How to choose a graph database

A graph database stores relationships as first-class data rather than as foreign keys reconstructed at query time, which makes multi-hop questions — "who is connected to whom, through how many steps, and by what" — fast at a scale where a relational join would slow to a crawl. Teams adopt one for fraud rings, recommendation engines, supply-chain lineage, identity resolution, or building a knowledge graph that connects data across systems that were never designed to talk to each other.

If your relationships are mostly one or two hops deep and a well-indexed relational table already answers your questions fast enough, you probably do not need a graph database yet. The category earns its cost once traversal depth or the number of relationship types grows past what joins handle cleanly.

Property graph or RDF — decide this before anything else

There are two largely separate traditions in this market, and they are not interchangeable.

• Property graphs store nodes and relationships directly, each with arbitrary key-value properties, and are queried with a graph-pattern language: Cypher (the language Neo4j originated, now the basis of the new ISO GQL standard), Gremlin (JanusGraph), GSQL (TigerGraph), nGQL (NebulaGraph), AQL (ArangoDB) or DQL (Dgraph). This is the model most teams reach for building fraud detection, recommendations or operational graph applications.
• RDF triple stores model data as subject-predicate-object triples, queried with SPARQL, and typically add OWL/RDFS reasoning to infer new facts from an ontology rather than only storing what was explicitly loaded. Ontotext GraphDB and Stardog are built for this — enterprise knowledge-graph, data-integration and semantic-search use cases where a shared vocabulary and inference matter more than raw traversal speed.
• Amazon Neptune is unusual in supporting both models on the same managed infrastructure, chosen per database instance at creation time.

Picking the wrong model is expensive to reverse — migrating from an RDF ontology to a property-graph schema, or back, is close to a rebuild, not a config change.

Managed, self-hosted, or both

Amazon Neptune is fully managed with no self-hosted option at all — AWS operates the cluster. JanusGraph and Dgraph are the reverse: self-hosted only, with no first-party managed cloud service. Everything else in this guide — ArangoDB, Memgraph, NebulaGraph, Neo4j, Ontotext GraphDB, Stardog and TigerGraph — offers both a managed cloud tier and a self-hosted or on-premises path, so the deployment question does not narrow the field as sharply as it might in other categories. It still matters: a team that wants to avoid operating a distributed database at all should weight the managed options more heavily regardless of which query language wins.

How the engine actually scales

• Native distribution with no external dependency: Dgraph and NebulaGraph shard and distribute natively, without requiring a separate coordination layer. NebulaGraph in particular is built and marketed for very large graphs — vendor material describes billion-vertex, trillion-edge scale.
• Pluggable storage on infrastructure you already run: JanusGraph has no storage engine of its own — it runs on Apache Cassandra, HBase, ScyllaDB or Bigtable, so a team already operating one of those reuses existing operational expertise instead of adopting a new storage system just for graph data.
• In-memory for latency-sensitive workloads: Memgraph is built in C++ and keeps the graph in memory, aimed at millisecond queries for fraud detection, real-time recommendations, and GraphRAG or agentic-AI memory rather than large-scale batch traversal.
• Massively parallel for deep traversals: TigerGraph's engine is built specifically for queries that traverse ten or more hops deep, where relational joins and many single-node graph databases struggle.
• Multi-model, one engine for several data shapes: ArangoDB combines graph, document and key-value storage under one engine and one query language, avoiding a separate document store alongside the graph database for the same application.

Open source, source-available, and ownership stability

Read licenses and ownership history here more carefully than in most categories, since both have shifted recently. JanusGraph (Apache-2.0) is a vendor-neutral Linux Foundation project with no single company behind it. Dgraph (Apache-2.0) is genuinely open source, but the project has changed hands twice — acquired by Hypermode in 2023, and Hypermode itself acquired by Istari Digital in October 2025 — so confirm current commercial support and managed-cloud availability directly before committing. NebulaGraph's Open-Source Edition is Apache-2.0 with a Commons Clause restriction limiting resale by cloud providers, which does not affect a normal end user. ArangoDB and Memgraph are both source-available under the Business Source License rather than an OSI-approved open-source license — free to use, including self-hosted, but not the same legal category as JanusGraph or Dgraph's core.

A shortlist by situation

• The most mature ecosystem — tooling, hiring pool, a built-in algorithms library — for fraud detection or recommendation work: Neo4j.
• A fully managed AWS service with the flexibility to choose property-graph or RDF on the same infrastructure: Amazon Neptune.
• Millisecond graph queries or GraphRAG/agent memory, with a Cypher-compatible query language: Memgraph.
• Deep multi-hop analytics — ten-plus hops — at large enterprise scale: TigerGraph.
• You already operate Cassandra, HBase or Bigtable and want to build a distributed graph on that infrastructure: JanusGraph.
• Very large graphs (social, recommendation, risk) with an open-source, storage-compute-separated architecture: NebulaGraph.
• Graph and document data in the same application, queried through one language: ArangoDB.
• A GraphQL-first application where the store and the API layer should be the same thing: Dgraph — confirm current support given its recent ownership changes.
• An ontology-driven enterprise knowledge graph needing OWL/RDFS reasoning and semantic search together: Ontotext GraphDB.
• A reasoning-capable knowledge layer federated live across existing relational systems, without a full data migration: Stardog.

Questions to ask vendors or in a trial

1. Does your actual use case need property-graph traversal, RDF reasoning, or both — and does the vendor genuinely support that model, not just tolerate it?
2. At your expected graph size, does the engine scale by adding nodes natively, or does it depend on a separate storage layer you also have to operate?
3. What does the managed tier cost at your data volume, not the trial or the smallest published tier?
4. If the vendor is a smaller company or has recently changed ownership, what is the support and roadmap commitment today?
5. Can you run your actual deepest, most relationship-heavy query — not a sample graph — during evaluation?

Common mistakes

• Choosing a property-graph engine for a problem that is really about ontology-driven reasoning, or vice versa, and discovering the mismatch only after modeling real data.
• Benchmarking on a small sample graph that fits comfortably in memory on every candidate, which hides the differences that show up at real depth and scale.
• Ignoring deployment model until late in the process, then finding out the preferred engine is managed-only or self-hosted-only when the opposite was assumed.
• Treating "open source" as a guarantee of stability without checking who maintains the project and whether ownership has changed recently.

See Amazon Neptune vs Neo4j and Neo4j vs TigerGraph, or browse every tool in this category.