Knowledge graph

In May 2012, Google's search box changed. Type "taj mahal" and it no longer just looked for pages with those two words. It knew you probably meant the monument. You might also mean the musician or the casino. And whichever one you meant came with its own set of facts that people usually ask about next.

Google's engineers gave this change a slogan that the whole field still uses: things, not strings. Behind it were more than 500 million things and 3.5 billion facts about how they relate. They called that structure a knowledge graph, and that name stuck too.

Here is the part that matters for you. Over the last seven concepts you defined entities, gave them properties, picked their keys, connected them with relationships, and bound all of it to real rows. You were not getting ready to build a knowledge graph. You were building one. You just have not watched it come together yet.

You do not draw it. It materializes.

Ask someone to picture a knowledge graph and they imagine a person drawing it: circles, arrows, a whiteboard, a long afternoon. That picture is wrong, and it is the most important thing to unlearn on this page.

Nobody draws the graph. The graph is derived (built from what you already set up). You made decisions: a Customer places Orders, an Order is carried on a Shipment, a Shipment is cooled by a Freezer. You bound those decisions to tables. The graph follows from the two, automatically: every bound row becomes a node, every key match becomes an edge.

That is why the graph stays correct. Add a row to the orders table and a new node appears with its edges already attached. Fix a wrong foreign key and the bad edge disappears. The graph is not a drawing of your business that slowly goes out of date. It is built from your live data, and it moves when the data moves.

Just below, you can press one button and watch it happen.

What makes it knowledge, and not just a graph

Here the experts really do disagree, so we will not pretend they agree. The one-line definition above is the academic view: a knowledge graph is simply a graph of data whose nodes are entities and whose edges are relations. The graph database world says that definition is missing a third part: organizing principles, a layer that says what the nodes and edges mean, so the graph holds knowledge and not just connections.

You already know which side you are on, because you built the third part first. The ontology is the organizing principle: it is the thing that says node 4471 is a Customer, that this edge means places and not mentions, and that a Customer can place many Orders. It is also the reason the graph can materialize at all. Rows can only become nodes, and key matches can only become edges, because the ontology already said what each one means.

Why this matters for an AI agent

An agent grounded in a knowledge graph does two things a table-bound agent cannot. It answers relationship questions by walking real edges, the traversal you saw in the last concept, instead of guessing joins. And it can show its work: the path it walked is the explanation, node by node, edge by edge.

What Fabric calls it, and where it runs

In Microsoft Fabric this assembled thing is the ontology graph: a queryable instance graph built from your data bindings and relationship definitions. Nodes are entity instances. Edges are links, either asserted from your data or derived by rules, and every node and edge keeps its source lineage (a record of where it came from). The official docs sum up the split of work in one line: the ontology declares what connects and why; the graph stores and traverses those connections. Behind the scenes it runs on Graph in Microsoft Fabric, which builds the graph over your OneLake tables in place, with no export and no separate graph database, and answers questions in GQL, the ISO-standard graph query language.

One warning before you build on it. The status is split, not one blanket answer. As of July 2026 the graph engine underneath is generally available, but the ontology item that tells the graph what any of it means is still in preview, and so is pointing a data agent at either one. The base is stable. The layer where you actually do your modeling is still changing. Check the status of the exact piece you plan to rely on, instead of trusting one summary line.

The one trap

Do not confuse a graph you can draw with a knowledge graph. A drawn graph is a picture: correct the day you drew it, then quietly wrong after that. A knowledge graph is derived from data, so it is only ever as current as the last refresh, and never more out of date than that. If you find yourself dragging nodes onto a canvas and typing their names, you are making a diagram, not a knowledge graph.

Next: the specific shape Fabric uses to store all this, where nodes and edges carry labels and properties. That shape has a name, the labeled property graph.