Cypher Query Language

Cypher's most distinctive feature is its use of ASCII-art to visually represent graph patterns. Nodes are depicted with parentheses (), relationships with arrows --> or <--, and properties with curly braces {}. This syntax makes complex graph traversals intuitive to read and write.

• Example: MATCH (p:Person)-[:LIVES_IN]->(c:City {name:'London'}) RETURN p.name
• The pattern (p:Person)-[:LIVES_IN]->(c:City) directly mirrors the visual structure of the graph, connecting a Person node to a City node via a LIVES_IN relationship.

Cypher is a declarative language, meaning you specify what data you want, not how to retrieve it. The query optimizer determines the most efficient execution plan (scan, index, join order). This separates query logic from execution mechanics, improving developer productivity and allowing the database engine to apply advanced optimizations like predicate pushdown and cost-based optimization.

• You declare patterns (MATCH), filters (WHERE), and results (RETURN).
• The engine handles traversal algorithms, index selection, and join ordering.

Cypher queries are composed of distinct, chainable clauses, each serving a specific purpose in the query pipeline. This modular structure promotes readability and logical flow.

Core clauses include:

• MATCH: Describes the graph pattern to find.
• WHERE: Adds constraints to filter patterns.
• RETURN: Specifies what data to output.
• CREATE / MERGE: Creates new graph elements or ensures they exist.
• SET / REMOVE: Updates properties and labels.
• DELETE: Removes elements.
• WITH: Pipes results between query parts, enabling complex multi-step operations.

Cypher is natively designed for the labeled property graph (LPG) model. This model's core components—nodes, relationships, labels, and properties—are first-class citizens in the language.

• Nodes: (:Person {name: 'Alice', age: 30})
• Relationships: Have direction, a type (e.g., :KNOWS), and can also hold properties [:KNOWS {since: 2019}].
• Labels (e.g., Person, Movie) group nodes and enable schema-like constraints and indexing.
• This native alignment allows Cypher to leverage storage optimizations like index-free adjacency for ultra-fast traversals.

Cypher excels at expressing complex, multi-hop graph patterns and path queries concisely. It provides powerful operators for variable-length paths, optional patterns, and path filtering.

Key pattern features:

• Variable-length Paths: (a)-[:FRIEND_OF*1..5]->(b) finds paths of 1 to 5 FRIEND_OF hops.
• Shortest Path: Built-in shortestPath() function for finding optimal routes.
• Optional Matching: OPTIONAL MATCH returns null for missing parts, acting like an outer join.
• Path Variables: Assign a path to a variable for later use: p = (a)-[*]->(b).

Cypher seamlessly integrates with graph analytics, allowing queries to invoke built-in graph algorithms and use their results for further filtering or aggregation. This blurs the line between transactional querying and analytical processing.

• Examples: MATCH (p:Person) RETURN p.name, centrality.pageRank(p)
• Algorithms like PageRank, community detection (Louvain), and shortest path (Dijkstra) can be called directly within a RETURN or WHERE clause.
• This enables powerful insights, such as finding influential entities or clustered communities, within a single query.

The MATCH clause is used to find patterns in the graph. It is the primary mechanism for reading data.

• Find a person named 'Alice': MATCH (p:Person {name: 'Alice'}) RETURN p
• Find Alice's friends: MATCH (p:Person {name: 'Alice'})-[:FRIEND_OF]->(friend) RETURN friend.name
• Find patterns of variable length: Use * for variable-length traversals. MATCH (p:Person)-[:FRIEND_OF*1..3]->(fof) RETURN DISTINCT fof.name finds friends up to 3 hops away.

The CREATE clause is used to insert new nodes and relationships into the graph.

• Create a node with a label and properties: CREATE (p:Person {name: 'Bob', age: 30})
• Create a relationship between existing nodes: First find the nodes, then create the link.

codeCopy
MATCH (a:Person {name: 'Alice'}), (b:Person {name: 'Bob'})
CREATE (a)-[:WORKS_WITH {since: 2020}]->(b)

• Create a full pattern in one statement: CREATE (c:Company {name: 'Acme'})<-[:WORKS_AT]-(p:Person {name: 'Charlie'})

SET updates properties on nodes or relationships. MERGE ensures a pattern exists, creating it if it doesn't (a 'get or create' operation).

• Update a property: MATCH (p:Person {name: 'Alice'}) SET p.age = 31
• Merge a node (create if not exists): MERGE (p:Person {name: 'David'}) ON CREATE SET p.created = timestamp()
• Merge a relationship: This ensures the connection exists without creating duplicate nodes.

codeCopy
MATCH (a:Person {name: 'Alice'}), (b:Person {name: 'Bob'})
MERGE (a)-[:FRIEND_OF]->(b)

Combine WHERE for filtering, WITH for piping intermediate results, and RETURN for final projection and aggregation.

• Filter with WHERE: MATCH (p:Person) WHERE p.age > 25 RETURN p.name
• Aggregate results: MATCH (p:Person)-[:WORKS_AT]->(c:Company) RETURN c.name, count(p) AS employeeCount
• Chain operations with WITH: WITH is like a pipeline. This finds people, filters, then counts:

codeCopy
MATCH (p:Person)
WITH p WHERE p.age >= 18
RETURN count(p) AS adults

Cypher has built-in functions for finding paths between nodes, which is a core strength of graph databases.

• Find any path: MATCH path = (a:Person {name: 'Alice'})-[:FRIEND_OF|WORKS_WITH*..5]-(b:Person {name: 'Zoe'}) RETURN path
• Find the shortest path: Use the shortestPath() function. This finds the fewest relationships connecting two nodes.

codeCopy
MATCH (a:Person {name: 'Alice'}), (b:Person {name: 'Zoe'})
MATCH p = shortestPath((a)-[*..15]-(b))
RETURN p

• Find all shortest paths: Use allShortestPaths() to find all paths tied for the shortest length.

DELETE removes nodes or relationships. DETACH DELETE removes a node and all its connected relationships.

• Delete a relationship: MATCH (a:Person {name: 'Alice'})-[r:FRIEND_OF]->(b:Person {name: 'Bob'}) DELETE r
• Delete a node (must have no relationships): MATCH (p:Person {name: 'Charlie'}) DELETE p
• Force delete a node and its relationships: MATCH (p:Person {name: 'David'}) DETACH DELETE p
• Delete all data: MATCH (n) DETACH DELETE n - Use with extreme caution.

The property graph model is the foundational data structure for which Cypher is designed. It consists of:

• Nodes (vertices) representing entities, which can have labels (types) and properties (key-value pairs).
• Relationships (edges) connecting nodes, which are always directed, have a single type, and can also contain properties.
• This model's flexibility and intuitive mapping to real-world data make it the dominant paradigm for enterprise knowledge graphs, directly enabling Cypher's expressive pattern-matching syntax.

Gremlin is a functional, imperative graph traversal language and virtual machine within the Apache TinkerPop framework. It serves as a primary alternative and complement to declarative Cypher.

• Imperative vs. Declarative: Where Cypher declares what pattern to find, Gremlin specifies how to walk the graph step-by-step.
• Machine Portability: Gremlin queries can run across any TinkerPop-enabled graph system (e.g., JanusGraph, Amazon Neptune).
• Use Case: Often used for complex, procedural graph algorithms and analytics where fine-grained control over the traversal path is required.

SPARQL 1.1 is the W3C-standardized query language for RDF triplestores, representing a different semantic web paradigm compared to Cypher's property graphs.

• Data Model: Queries over triples (subject-predicate-object) rather than labeled property graphs.
• Capabilities: Supports sophisticated graph pattern matching, aggregation, subqueries, and update operations.
• Interoperability: Designed for the open web of linked data, whereas Cypher is often used for closed, enterprise-domain knowledge graphs. The choice between them is fundamentally a choice between RDF and LPG data models.

Index-free adjacency is a native graph storage principle that enables Cypher's fast traversals. In a natively stored graph database like Neo4j:

• Each node maintains direct physical pointers to its connected relationships (edges).
• Traversing from one node to its neighbors is a constant-time operation, akin to a pointer dereference in RAM, without requiring a global index lookup.
• This is the architectural foundation that makes Cypher path queries (()-[:KNOWS*2..5]->()) efficient, as the engine can 'walk' the stored graph structure directly.

A query plan is the sequence of low-level operations (e.g., NodeByLabelScan, Expand, Filter) generated by the Cypher query planner and optimizer to execute a high-level MATCH clause. Using the EXPLAIN or PROFILE keywords reveals this plan.

• Planner: Translates Cypher into an initial logical plan.
• Optimizer: Applies rules (heuristic optimization) and cost estimates (cost-based optimization) to transform the plan into a more efficient form (e.g., selecting indexes, reordering patterns).
• Analysis: The EXPLAIN output is critical for database engineers to diagnose performance bottlenecks and understand how a Cypher statement will be executed.

Graph traversal is the core computational operation underlying any Cypher pattern match. It is the process of systematically visiting nodes and edges in a graph.

• Pathfinding: Cypher's variable-length paths (*) implement algorithms like depth-limited depth-first search.
• Traversal Direction: Relationships in patterns are directional (->, <-), guiding the traversal walk.
• Foundation: While Cypher is declarative, its runtime engine performs traversals to locate subgraphs that satisfy the specified patterns. Understanding traversal complexity is key to writing performant queries.