Graph databases have matured to the point where the question is no longer “should I use one” but “which one fits my workload.” ArangoDB and Neo4j are the two most prominent options. They share the ability to store and traverse connected data, but they are built on different philosophies – and that difference matters when you choose one for production.
The Core Distinction
Neo4j is a purpose-built graph database. Everything – the storage engine, the query language, the indexing strategy – is designed around one primitive: nodes connected by typed, directed relationships with properties on both. It does one thing and does it extremely well.
ArangoDB is a multi-model database. A single ArangoDB instance stores documents, graphs, and key-value data. You can run graph traversals over document collections without ETL, and you can mix document queries with graph hops in a single query. The tradeoff is that the graph engine is not as deeply specialized as Neo4j’s.
Query Languages
Neo4j uses Cypher, a pattern-matching language that reads almost like ASCII art of the graph:
MATCH (a:Person {name: "Alice"})-[:KNOWS]->(b:Person)
WHERE b.city = "Hanoi"
RETURN b.name, b.age
Cypher is widely regarded as one of the most readable query languages for graph problems. The (node)-[relationship]->(node) syntax maps directly to how humans think about connected data. Cypher is now also an open standard (openCypher), adopted by several other databases.
ArangoDB uses AQL (ArangoDB Query Language), which covers documents, key-value, and graph operations in one syntax:
FOR v, e, p IN 1..2 OUTBOUND 'persons/alice' GRAPH 'social'
FILTER v.city == "Hanoi"
RETURN { name: v.name, age: v.age }AQL is powerful but more verbose for pure graph work. Where it shines is mixed queries – joining graph traversal results with document lookups in a single pass, without leaving the query engine.
Data Model
Neo4j uses a property graph model: nodes have labels and properties, relationships have types and properties. The schema is flexible – you define it by what you store, not by DDL. Relationships are first-class citizens stored as direct pointers, which is why deep traversals are fast: each hop is a pointer follow, not a join.
ArangoDB uses document collections as its base unit. A “graph” in ArangoDB is defined by designating certain collections as vertex collections and others as edge collections. The edge documents contain _from and _to fields pointing to vertices. This means the graph layer sits on top of the document layer – flexible, but with slightly more overhead per hop than Neo4j’s native pointer structure.
Performance
For pure graph traversal – deep multi-hop queries over densely connected data – Neo4j is typically faster. Its storage engine is designed so that traversal cost scales with the number of hops and the local neighborhood, not with the total size of the graph. A 6-hop traversal over a billion-node graph is not significantly slower than the same traversal over a million-node graph, if the traversal touches a small subgraph.
ArangoDB is competitive for shallow traversals (1-3 hops) and for mixed workloads where you need both document queries and graph lookups. If your application is 70% document operations with occasional graph queries, ArangoDB avoids the operational complexity of running two separate databases.
Graph Algorithms and Analytics
Neo4j’s Graph Data Science (GDS) library is a significant differentiator. It includes production-grade implementations of:
- PageRank and centrality measures
- Community detection (Louvain, Label Propagation)
- Shortest path algorithms (Dijkstra, A*)
- Similarity metrics (Jaccard, Node2Vec embeddings)
- Link prediction
These run in-process against the graph, not via exported datasets. If your use case involves fraud detection, recommendation engines, or network analysis, GDS saves substantial engineering work.
ArangoDB has graph algorithm support via Pregel (distributed graph processing) and its SmartGraph feature for sharded graph workloads. The algorithm library is smaller than GDS, but the basics (shortest path, connected components, PageRank) are present.
Scalability
Neo4j scales vertically well and supports horizontal read scaling via causal clustering (write to one primary, read from replicas). True horizontal write scaling has historically required careful architecture – the graph’s connected nature makes sharding non-trivial. Neo4j’s AuraDB cloud service manages this complexity for you.
ArangoDB supports horizontal sharding natively, including SmartGraphs which attempt to co-locate connected vertices on the same shard to minimize network hops during traversal. For write-heavy distributed graph workloads, ArangoDB’s sharding story is more straightforward than Neo4j’s.
Ecosystem and Tooling
Neo4j has a larger graph-specific ecosystem built up over more than 15 years:
- Neo4j Bloom – visual graph exploration for non-technical users
- Neo4j Browser – query console with graph visualization
- Drivers for every major language, all officially maintained
- GraphQL support via the Neo4j GraphQL library
- Deep integrations with data science tools (Python, R, Spark)
ArangoDB’s tooling is solid but narrower – Aardvark is the web UI for queries and collection management, and drivers exist for all major languages. The multi-model nature means the tooling covers all three storage models, which is breadth at the cost of depth in any one area.
When to Choose Neo4j
- The core problem is fundamentally a graph problem: fraud detection, recommendation engines, identity graphs, knowledge graphs, network topology
- You need deep multi-hop traversals over dense, highly connected data
- Your team will benefit from Cypher’s readability and the GDS algorithm library
- You want a managed cloud option (AuraDB) with minimal operational overhead
When to Choose ArangoDB
- Your data is a mix of documents and relationships – you need both, not just one
- You want one database instance for multiple data models, reducing operational surface area
- Shallow graph traversals combined with document queries are the primary pattern
- You need distributed write scaling with a simpler sharding model
- The Foxx microservices layer (JavaScript stored procedures running inside ArangoDB) fits your architecture
The Honest Summary
If your application is a graph problem, use Neo4j. The specialized storage engine, Cypher’s expressiveness, and the GDS library are hard to beat for connected data at scale.
If your application needs graphs as one part of a broader data model – documents plus some relationships, or mixed queries that blend traversal with filtering on document properties – ArangoDB’s multi-model approach avoids the overhead of running separate systems. You trade some graph performance for operational simplicity and query flexibility.
Neither is a wrong choice. The decision comes down to whether your graph is the center of gravity for your data or one layer among several.