ArangoDB vs. Neo4J

Estimated reading time: 7 minutes

Advantages & Implications for Architects and Developers

ArangoDB and Neo4j are both powerful graph databases, but they have different strengths and features. Here’s a comparison showing how ArangoDB might be superior to Neo4j in certain scenarios, along with code snippets to illustrate:

1. Multi-Model Capabilities

ArangoDB: ArangoDB is a multi-model database, meaning it supports graphs, documents, and key-value data within a single database. This flexibility can simplify data management by allowing different data types to coexist and interact seamlessly.

Code Snippet:

// Create collections for documents and graphs
db._createDocumentCollection(“products”);
db._createGraph(“supply_chain”, {
edgeDefinitions: [
{
collection: “supplies”,
from: [“products”],
to: [“suppliers”]
}
]
});

// Add a document
db.products.save({ _key: “p1”, name: “Widget” });

// Add a graph edge
let graph = db._graphs.supply_chain;
graph.edgeCollection(“supplies”).save({ _from: “products/p1”, _to: “suppliers/s1” });

This AQL (ArangoDB Query Language) code snippet demonstrates how ArangoDB’s multi-model capabilities simplify data management by allowing documents and graphs to coexist and interact seamlessly within a single database. It creates collections for both document data (“products”) and graph data (“supply_chain”) and then adds a document and an edge to the graph, showcasing the integration of different data types.

This flexibility is just one of the reasons G2 users rate ArangoDB higher than Neo4j in almost every category.

Neo4j: Neo4j is primarily a graph database and does not natively support other data models like documents or key-value pairs. You would need to use Neo4j in conjunction with other databases if you need these additional data types.

Code Snippet:

// Create nodes and relationships
CREATE (p:Product {id: “p1”, name: “Widget”})
CREATE (s:Supplier {id: “s1”})
CREATE (p)-[:SUPPLIED_BY]->(s)

The Neo4j code is creating nodes and linking them together in a graph using Cypher, which is simple but stuck in a graph-only world. ArangoDB’s AQL, on the other hand, lets you mix and match data types, scales better across systems, and handles both graph and document data with ease.

To see specific examples of companies that chose ArangoDB over Neo4j because of the multi-model support, check out this video.

2. Query Language Versatility

ArangoDB: ArangoDB uses AQL which can handle complex queries across different data models. It allows you to query documents, graphs, and key-value pairs in a unified way.

Code Snippet:

// Query combining documents and graph data
FOR product IN products
FILTER product.name == “Widget”
FOR supplier IN 1..2 OUTBOUND product supplies
RETURN { product, supplier }

This AQL snippet demonstrates the language’s power and flexibility by first iterating over the products collection to find the product named “Widget.” Then, it navigates the graph relationships OUTBOUND from the product to find suppliers up to two levels deep. The code’s structure is concise, yet it handles complex tasks—combining filtering, traversal, and data retrieval all in one query. AQL’s ability to seamlessly integrate these operations into a single, readable block of code highlights its strength in managing intricate data relationships efficiently, giving developers precise control over their queries.

And if you know SQL, picking up AQL is a breeze. The syntax is pretty similar, so you can jump right in without feeling lost. AQL feels like a natural extension of SQL, making it easier to tackle complex queries. Cypher, on the other hand, has a steeper learning curve since it’s more specialized for graph stuff.

Neo4j: Neo4j uses Cypher, which is optimized for graph queries but does not handle non-graph data directly. Complex queries that mix document-style data and graph data require additional processing or external tools.

// Find products and their suppliers
MATCH (p:Product)-[:SUPPLIED_BY]->(s:Supplier)
WHERE p.name = “Widget”
RETURN p, s

This Cypher snippet efficiently finds a product named “Widget” and its suppliers, but it highlights some limitations in Cypher’s flexibility. For example, the MATCH clause is straightforward but rigid—it’s designed purely for graph traversal, so if you needed to filter or combine this data with non-graph elements, you’d hit a wall. The WHERE clause filters by product name, but integrating more complex conditions or joining with non-graph data isn’t as seamless.

Cypher’s syntax, while clear for graph operations, lacks the power to handle more intricate, multi-step queries without becoming convoluted or requiring additional processing outside the query itself. Compared to AQL, which can elegantly handle complex operations in a single, cohesive query, Cypher often forces you to break things up, leading to more cumbersome and less efficient code.

ArangoDB’s AQL versatility is a major reason companies move from Neo4j to ArangoDB.

3. Performance for Mixed Workloads

ArangoDB: ArangoDB can be more efficient for applications that require mixed workloads involving documents and graphs, as it avoids the need to use multiple databases and can optimize queries across different data models.

Code Snippet:

// Complex mixed query example
FOR product IN products
FILTER product.category == “Electronics”
LET suppliers = (
FOR s IN 1..2 OUTBOUND product supplies
RETURN s
)
RETURN { product, suppliers }

This AQL snippet showcases ArangoDB’s efficiency in handling mixed workloads. It first filters products by category, like “Electronics,” and then uses a nested query to find related suppliers up to two levels deep. The power here lies in AQL’s ability to seamlessly combine document filtering with graph traversal in a single query. The LET clause elegantly handles complex operations, storing the results of the graph traversal for later use in the RETURN statement. Unlike Cypher, which struggles with such mixed queries, AQL’s syntax allows you to perform multiple, diverse operations within a cohesive and efficient query, making it a strong choice for applications needing to handle both document and graph data without compromising performance.

Neo4j: Neo4j’s performance is highly optimized for graph queries but may require additional effort or integration with other systems to handle non-graph data efficiently.

Code Snippet:

// Example of separate graph and document queries (would require integration with other data
sources)
MATCH (p:Product)-[:SUPPLIED_BY]->(s:Supplier)
WHERE p.category = “Electronics”
RETURN p, s

This Cypher snippet is solid for finding products in the “Electronics” category and their suppliers using the MATCH clause for graph traversal. However, where Cypher falls short is in handling more complex, nested queries. For instance, if you wanted to dig deeper into relationships—like finding suppliers and then pulling related data from other entities—you’d run into limitations. Cypher isn’t designed for complex multi-step operations within a single query. It’s great for straightforward graph tasks, but when you need to perform more sophisticated, layered queries, especially those requiring nested logic, Cypher can become cumbersome. You’d often need to break it down into multiple queries or use additional tools, which can complicate your workflow. In contrast, AQL handles these kinds of nested, multi-layered operations effortlessly, allowing you to keep everything streamlined and within a single, powerful query.

4. Schema Flexibility

ArangoDB: ArangoDB provides schema flexibility by allowing dynamic schemas and easy changes to data models. This is useful for evolving data requirements.

Code Snippet:

// Define a flexible schema
db.products.save({ _key: “p1”, name: “Widget”, price: 29.99, inStock: true });

This AQL snippet is a great example of ArangoDB’s schema flexibility. Here, you’re saving a product with attributes like name, price, and inStock using the db.products.save function. What’s cool is that you don’t need to worry about a rigid schema—ArangoDB lets you throw in new fields or change existing ones without any hassle. This makes it super easy to adapt your data model as your project evolves. Need to add a new attribute later? No problem, just include it in your save function. Unlike traditional databases where you’d have to mess with predefined schemas, ArangoDB lets you stay agile, adjusting on the fly to meet changing requirements. This flexibility keeps your development process smooth and headache-free.

Neo4j: Neo4j’s schema is more rigid in that it primarily focuses on graph structures, and changes to node properties or relationships require more manual updates.

Code Snippet:

// Update properties of a node
MATCH (p:Product {name: “Widget”})
SET p.price = 29.99, p.inStock = true
RETURN p

This Cypher snippet shows how Neo4j handles updating a product’s properties. You find the “Widget” product with MATCH and then use SET to tweak its price and inStock status. It works, but Neo4j’s schema can be pretty rigid. If you need to add new properties or change relationships, you have to manually update each node or connection, which can be a pain as your data changes. Neo4j’s great for graph stuff, but it’s not as flexible when you need to adapt quickly. You end up doing more manual work, which can slow things down when your project’s data needs are constantly evolving.

Summary

ArangoDB’s multi-model support, flexible query language, and strong performance with mixed workloads give it a big edge over Neo4j when you need to integrate different data types and handle complex queries. That said, Neo4j really shines in graph-specific use cases, thanks to its super-optimized graph processing. So, if your application is all about graphs, Neo4j could be the better fit. Ultimately, it comes down to what your project needs—whether you require versatility across data types or focused graph capabilities.

But remember: relying on a graph-only database like Neo4j can limit flexibility, making it harder to adapt to evolving data requirements that may involve integrating non-graph data or handling mixed workloads efficiently.

For an even more in-depth look at the technical differentiation of ArangoDB’s AQL vs. Neo4j’s Cypher, check out this Technical Brief.