The Ontology node supports three query languages against the unified entity graph: Gremlin and openCypher for relationship traversal, and SQL for relational-style queries against a flat view of the model. A critical scoping rule applies to all graph queries — they are not automatically constrained to your model, so always include a model filter or risk returning data from unintended entity models.
Overview
Once golden records exist in the entity graph, you query them using the language that fits the question. Graph traversal languages suit relationship-heavy questions; SQL suits aggregation and tabular queries. A dedicated audit operation is also available for tracking changes to MDM records over time. The scoping gotcha applies to every Gremlin and openCypher query — it is not optional.
Gremlin Queries
Gremlin is a graph traversal language designed for navigating relationships across the entity graph. Use it for relationship-heavy questions such as "which accounts connect to this customer" or "what is the path between these two entities." Gremlin traversals follow edges (relationships) between vertices (entities), making them well suited to multi-hop traversal questions.
Because graph queries are not automatically scoped to your model, every Gremlin query must include an explicit model filter. Without it, the traversal can reach across into other models' data.
openCypher Queries
openCypher is a second graph traversal language supported by the Ontology node. Like Gremlin, it is designed for relationship-heavy queries and traverses the same property graph. If your team is already familiar with Cypher syntax from other graph databases, openCypher provides a comparable experience against the Ontology entity graph.
The same scoping rule applies: openCypher traversals are not automatically scoped to your model. Always include a model filter in every openCypher query.
SQL Queries
SQL queries run against a relational view of the entity model. Use SQL when the question is aggregation-focused or tabular — for example, counting entities by attribute, grouping records, or selecting flat field values without traversing relationships. SQL does not traverse the graph, so it cannot follow relationship edges between entities.
The Model-Scoping Gotcha
Graph queries — both Gremlin and openCypher — are not automatically scoped to your model. If you do not include a model filter in the query, a traversal can reach across into other models' data and return results from unintended entity models.
Always filter by model: Include a model filter in every Gremlin and openCypher query. This is not an optional optimization — cross-model data appearing in results is a real risk for unconstrained traversals.
Unconstrained graph traversals can also be expensive on large graphs. Applying model and entity filters limits the traversal scope and keeps queries performant.
Audit Retrieval
A dedicated audit retrieval operation is available for tracking changes to MDM records over time. Use it to answer questions such as "who changed this golden record and when" or "what was the value of this field before the last update." The audit retrieval is separate from the three query languages — use it specifically for change-history questions, not for current-state entity queries.
Notes
Choosing the right query language for the question avoids both incorrect results and unnecessary performance cost.
Graph queries (Gremlin and openCypher) are not automatically scoped to your model — always include a model filter or risk returning data from other models.
SQL queries run against a relational view and do not traverse relationships — use graph queries for relationship-heavy or multi-hop questions.
Gremlin and openCypher are both supported; choose based on your team's familiarity and the query pattern at hand.
The audit retrieval is separate from the query operations — use it for change-history and data-lineage questions, not current entity state.
Apply model and entity filters to all graph queries to limit traversal scope and avoid cross-model data leakage.
Treat the model filter as a required element of every graph query, not an optional optimization — it prevents cross-model data from appearing in results.