Graph query (GQL)

The question came in on a night shift. A freezer had breached its safe temperature, and someone needed the list of customers whose orders it had touched, before those orders left the dock.

In SQL that is not one question. It is four tables you join together by hand. Freezers join to shipments on one key. Shipments join to orders on another key. Orders join to customers on a third. Line up the wrong column, or drop one join, and you still get an answer that looks clean. It just happens to be wrong, and nobody can see that from the result.

Now look at the right side of that figure. The same question, written a different way: one line that names the path from freezer to customer. No joins. No keys to line up. You draw the shape and the engine finds it.

You describe a shape, not a procedure

A SQL join is a procedure. You tell the database how to reach the answer: start here, join on this key, then that key, then filter. Every step is yours to get right, and the query is a list of instructions.

A graph query is a description. You tell the engine what the answer looks like, a path of a certain shape, and let it find every place that shape shows up. It is like the difference between giving someone step-by-step directions and giving them a photo of the house and saying "find this one." With the photo, it does not matter which streets they take.

That is why the keys disappear from the query. In a graph, the connections are already there as edges, built when the graph was materialized. The pattern names the edges by their meaning, COOLS, CARRIES, PLACED_BY, and the engine follows them. You never write freezer_id = f.id again. The edge already is that match, resolved once when the data was loaded.

MATCH, then WHERE, then RETURN

A graph query has three steps, and if you know SQL you already know all three. They are just aimed at a path instead of a table.

MATCH draws the shape you are looking for. WHERE keeps only the places the shape actually holds, here the freezers that breached rather than all of them. RETURN says which part of each match you want back, the customer at the end of the path and not the whole chain. Aggregates, ORDER BY, and LIMIT stack on top the way they do in SQL. The grammar is small on purpose.

Build one yourself. Add the pattern a segment at a time and watch the matching subgraph light up while the rest of the graph fades.

MATCH …

Two things are worth noticing as you play. First, adding a hop never rewrites the earlier part of the query. The pattern grows. It does not get re-planned. Second, the WHERE clause does not fetch anything new. It narrows the same shape down to the freezer that breached, and the answer narrows to exactly the customers at risk. That is the night-shift question, answered in one line.

GQL, and where Fabric runs it

The language has a name and a standard behind it. GQL is ISO/IEC 39075, published in 2024. It is the first brand-new database query language ISO has standardized since SQL itself. It is built on the three steps you just used: MATCH describes a path of nodes and edges, WHERE filters it, and RETURN picks the columns you want, with aggregates, ORDER BY, and LIMIT on top.

Graph in Microsoft Fabric speaks GQL. You ask a question as a pattern and it answers over your OneLake tables in place. There is no export into a separate graph database, no second copy to keep in sync with the source. The knowledge graph you materialized in the last concept is the thing the pattern walks, and every node and edge still points back to the OneLake row it came from.

You rarely type GQL by hand in the product. The data agent, Fabric's name for an AI agent grounded in your data, takes your plain-English question and turns it into a GQL pattern for you, then walks the graph to answer. That is the GraphRAG idea in action: the agent retrieves by traversing real edges, not by guessing a join, so its answer comes with a path you can inspect.

Two honesty notes before you rely on it. First, "Fabric speaks GQL" is true, but it sounds bigger than it is. The graph engine itself is generally available as of July 2026, and Microsoft documents it as supporting the ISO standard. That means it lines up with the standard, not that it passes a full conformance test. Coverage is still growing: the docs describe pattern matching, path constructs, and aggregations arriving as they are released, and undirected edges are not supported yet. Around the engine, the ontology item is still in preview, and so is pointing a data agent at a graph. So check the status of the piece you actually plan to rely on.

Second, the lab on this site runs a real teaching subset of GQL. It is enough to try MATCH, WHERE, and RETURN for yourself, not a fully conformant engine.

The one trap

Do not confuse the language with the power behind it. GQL is easy to read, and that ease can fool you into thinking the query is where the work is. It is not. A pattern is only as truthful as the graph under it. MATCH over a graph with a missing edge returns a smaller answer and says nothing about what it missed. That is the same silent wrong-answer failure as a dropped join, just harder to spot because the query looks so clean. The real work happened earlier: the entities, the keys, the relationships, and the bindings that put the right edges there in the first place.

That idea ties this whole track together. Every clean pattern you just wrote rests on one thing that declared what a Freezer is, what COOLS means, and which rows become which nodes. That thing has a name, and it has been under every concept from the start. Next: the ontology.