1. What Virtual Cypher is
A normal knowledge-graph query reads nodes and edges that are persisted in the graph. Virtual Cypher lets one Cypher query also traverse to data that is not in the graph — a HubSpot contact, a GitHub issue, a semantically-related email thread — by fetching it on demand the moment the query reaches for it, splicing it into the graph transiently for the life of that one query, and then rolling it back. The query author writes ordinary Cypher; they do not know, and do not need to know, which labels are persisted and which are fetched live.
The defining property: one MATCH spans persisted and live data uniformly.
MATCH (me:AssistantUser)-[:EMAILED]->(p:Person)-[:HAS_GITHUB]->(g:GitHubIdentity)-[:RAISED]->(i:GitHubIssue)RETURN p.name, i.titleAssistantUser, EMAILED, Person are persisted (the contact graph). GitHubIdentity,
HAS_GITHUB, RAISED, GitHubIssue are virtual — resolved from GitHub through the connecting
user’s credentials when the query runs. The author wrote one query; the engine decided what to
fetch.
The mental model
Section titled “The mental model”Think of a virtual label as a view over an external system that materializes only the rows a query touches. The closest analogues:
- A SQL foreign data wrapper / external table — but reached through graph traversal, so the anchor you start from decides which external rows are fetched.
- A LOTUS / Cortex semantic operator — but expressed inside Cypher, so structure (who emailed whom) and meaning (which threads are about X) compose in one query (see §6, vector edges).
You never call Virtual Cypher directly. You declare the pieces and the engine plans and runs the fetch.