Understanding How Neo4j Cypher Queries are Evaluated

There are many ways to store and manage data within a Neo4j graph database. When Neo4j 2.0 launched late last year we had an entirely new browser experience for interacting with graphs. The graph visualization from the return results of Cypher queries were at the core of the user experience enhancements to the platform.

Knowing how the data is generated, filtered, and processed is tremendously helpful for understanding how to optimize queries for the best performance.

For most users that use the Neo4j browser, this is an ideal experience for learning and designing great graph data models for querying. For applications that require a deeper control over how graphs are stored and queried, the native Java API provides a great deal of benefits. When using the Java API you gain a degree of freedom to tell Neo4j how to query your data.

The Cypher query language, with an innovative SQL-like syntax for graphs, is a declarative query language. That means you tell Neo4j what you want and not how to get it. When you run a Cypher query you are expressing to the graph database what you want from it. In turn, Neo4j maintains a compiler that translates that query into an execution plan that describes a set of data operations, arranged such that data is obtained from the graph and processed sequentially through each operation until a result is generated for the user.

What does an execution plan look like?

The typical approach for interacting with Neo4j involves sending a Cypher query and parameters in a POST request to the Neo4j database server. We call the frameworks or libraries that manage wrappers around the REST API methods of Neo4j from an arbitrary programming language a “driver”. These drivers transport queries and results over the network and Neo4j further translates the declarative syntax of Cypher into an execution plan.

Read more →