Best Practices for Using Cypher

On this page

Designing Efficient Queries
Data Modeling Tips
Common Pitfalls and How to Avoid Them

While it’s easy to get started with Cypher, writing efficient queries and properly modeling your data can be more challenging. This page provides some best practices for using Cypher effectively.

Designing Efficient Queries

The performance of a Cypher query can be heavily influenced by its structure. Here are a few tips for designing efficient queries:

Minimize the search space: The more data your query needs to process, the slower it will be. Try to structure your queries to eliminate irrelevant data as early as possible.
```
// Inefficient
MATCH (p:Person)
WHERE p.name = 'John Doe'
RETURN p

// Efficient
MATCH (p:Person { name: 'John Doe' })
RETURN p
```

Use labels: Using labels in your queries allows Neo4j to skip nodes that can’t possibly match.

// Inefficient
MATCH (n)
WHERE n.name = 'John Doe'
RETURN n

// Efficient
MATCH (p:Person { name: 'John Doe' })
RETURN p

Use indexes: If you’re frequently querying for nodes based on a specific property, consider adding an index on that property to speed up these queries.
```
// Add an index on Person.name
CREATE INDEX person_name FOR (p:Person) ON (p.name)
```

Data Modeling Tips

The way you model your data can also have a big impact on query performance. Here are some tips:

Use relationships: In a graph database, relationships are first-class citizens and are just as important as nodes. Using relationships to model your data can often be more efficient than storing data in node properties.
Avoid dense nodes: Nodes with many relationships can become bottlenecks in your queries. If possible, try to model your data in a way that avoids dense nodes.
Choose property types wisely: Certain types of properties (like numbers and dates) are more efficiently indexed and queried than others (like strings).

Common Pitfalls and How to Avoid Them

Finally, here are a few common pitfalls to avoid:

Avoid cartesian products: If you’re not careful, it’s easy to accidentally create a cartesian product in your queries, which can quickly lead to performance issues. Always ensure that all parts of your MATCH clauses are connected.
```
// Creates a cartesian product
MATCH (p:Person), (c:City)
RETURN p, c

// Avoids a cartesian product
MATCH (p:Person)-[:LIVES_IN]->(c:City)
RETURN p, c
```
Be careful with optional relationships: Optional relationships can often lead to larger result sets than expected, which can slow down your queries. Use them sparingly.
Avoid write operations in read queries: Mixing write operations (like CREATE and SET) with read operations (like MATCH and RETURN) can lead to unexpected results and performance issues. It’s often better to separate these into separate queries.

Advanced Topics

CQL

Quick Search Results

Designing Efficient Queries

Data Modeling Tips

Common Pitfalls and How to Avoid Them