Writing Cypher Queries That Don’t Lose Your Data

Using a small Neo4j test graph of three learners with different levels of course activity, including one user with no relationships, the post demonstrates how mandatory Cypher relationship patterns can unintentionally exclude unconnected nodes from results. It explains that `MERGE` patterns should contain only stable identity properties, such as email addresses, while mutable details belong in `SET` to avoid duplicate nodes. A query matching users through enrolments and courses returns only users who satisfy every relationship requirement, causing new or inactive users to disappear despite existing in the database. To preserve all users, the recommended approach is to anchor the query on the primary nodes and retrieve optional related information with list comprehensions, `COUNT {}` patterns, or `COLLECT {}` subqueries, which can yield empty lists or zero counts without removing rows. Although `OPTIONAL MATCH` can also include missing relationships, chaining several optional matches can multiply rows and create unnecessary work, whereas separate list expressions avoid duplication. The broader lesson is that dashboards and reports can overlook precisely the unconnected customers, employees, or learners who may need attention, so queries should be reviewed for implicit requirements before concluding that data is absent.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.