Your First Cypher Queries

Welcome back to Introduction to Graph Databases with Neo4j! In the previous lesson, we explored the fundamental concepts of graph databases: nodes, relationships, and properties. We learned how graph databases differ from traditional databases and why they excel at handling connected data, like our ConnectHub social network.

Now it's time to get hands-on. In this second unit, we'll write our first queries to retrieve data from the graph. By the end of this lesson, you'll be able to ask the database questions and get meaningful answers back. We'll start simply and gradually build up your querying skills.

Every database needs a way to communicate with it—a language for asking questions and getting answers. For Neo4j, that language is Cypher. Just as SQL is the standard query language for relational databases, Cypher is designed specifically for graph databases.

What makes Cypher special is its visual and intuitive syntax. Instead of thinking in terms of tables and joins, Cypher lets us describe patterns in the graph. The syntax resembles ASCII art drawings of nodes and relationships, making queries easier to read and understand. For example, we might describe a pattern like (person)-[:FRIENDS_WITH]->(friend), which visually represents a friendship connection. Don't worry if that looks unfamiliar—this unit focuses on querying nodes, and we'll cover relationships in a later lesson.

The foundation of most Cypher queries is the MATCH keyword. Think of MATCH as saying, "Find me this pattern in the graph." We describe what we're looking for, and Neo4j searches the graph to find all instances that match our description.

When we write a MATCH clause, we specify the pattern using parentheses for nodes and labels to identify their type. Labels are like categories or types that classify nodes. In our ConnectHub network, we have labels like User for people and Post for content they've created.

Finding patterns is only half the story; we also need to specify what information we want back. That's where the RETURN keyword comes in. After MATCH finds the patterns we described, RETURN tells Neo4j which parts of those patterns to send back to us. Results are always returned as a table, where each row represents one matched result and each column corresponds to something we asked for.

RETURN is flexible: we can ask for entire nodes with all their properties, or we can be selective and request only specific properties. This flexibility lets us tailor our queries to get exactly the information we need without unnecessary data. For example, returning all users might produce a table like this:

Let's write our first complete query to retrieve all users from the ConnectHub network:

MATCH (person:User)
RETURN person

This query has two parts. The MATCH clause says, "Find all nodes with the label User and call them person." The RETURN clause says, "Give me back those complete person nodes." Together, they retrieve every user in our network along with all their properties.

When this query runs, we'll see a collection of user nodes, each containing properties like name, email, age, and city. This is our first glimpse into the actual data stored in our graph database.

While seeing complete nodes is useful, often we only need specific pieces of information. In Cypher, we access a node's properties using dot notation, similar to how we access object properties in many programming languages.

The syntax is straightforward: nodeName.propertyName. For example, person.name accesses the name property of a person node, while person.city accesses their city. This notation allows us to be precise about which data we want to retrieve.

Now let's retrieve just the names of all users instead of complete nodes:

MATCH (person:User)
RETURN person.name

Notice how only the RETURN clause changed. We still MATCH the same pattern, but now we're returning only the name property of each user. This query is more focused: instead of getting complete user information, we get a simple list of names.

This approach is particularly useful when working with large datasets or when building user interfaces that only need to display certain fields. We reduce the amount of data transferred and make our results easier to work with.

We're not limited to returning just one property. We can request multiple properties by separating them with commas:

MATCH (person:User)
RETURN person.name, person.city

This query returns both the name and city for each user. The result will be a table-like structure with two columns, one for each property we requested. Each row represents one user, showing where they're from alongside their name.

This flexibility lets us build custom views of our data, selecting exactly the fields relevant to our current needs. We might want name and city for a location-based feature, or name and email for a contact list.

There's an important distinction between returning complete nodes and returning specific properties. When we RETURN person, we get the entire node object with all its properties and metadata. This is comprehensive but can include more information than we need.

When we RETURN person.name or RETURN person.name, person.city, we get just those specific values. The results are simpler and more focused, but we lose access to other properties and node information.

Choose full nodes when you need complete flexibility or when you'll be working with the node further. Choose specific properties when you know exactly what information you need and want clean, focused results. In practice, specific properties are often preferred for performance and clarity.

In this lesson, we've taken our first steps into querying graph databases with Cypher. We learned how the MATCH keyword finds patterns in the graph and how RETURN specifies what data to retrieve. We explored retrieving complete nodes versus specific properties and discovered how to select multiple properties in a single query.

You now have the foundational skills to retrieve data from Neo4j. These simple queries are the building blocks for more complex operations we'll explore later. Ready to put your new knowledge to work? In the upcoming practice exercises, you'll write your own queries against the ConnectHub network and see the results firsthand!