Relational databases are great at storing facts.
They’re not always great at showing you how those facts connect to each other.
Ask a table who influences whom, which accounts are quietly connected through three shared addresses, or how one delayed shipment ripples through a supply chain, and you’ll be writing joins for a week, if the question is even answerable at all.
That’s the gap Graph in Microsoft Fabric is built to close.
What Graph in Microsoft Fabric Actually Does
Graph is a Fabric workload built for modeling, visualizing, and querying relationships, not just the records on either end of them. Instead of storing rows in tables and reconstructing connections through joins every time you ask a question, graph stores the relationships themselves as first-class objects. Items become nodes, connections become edges, and both can carry their own descriptive tags.
It runs directly on OneLake, using a scale-out architecture built around the labeled property graph model, and it speaks GQL, the ISO standard graph query language, along with natural language to GQL translation. None of it requires copying your data into a separate specialized database first.
Why Relationships Break Relational Models
Relational tables handle one or two hops of a relationship reasonably well. A customer places an order, an order contains products, fine. The trouble starts when the question involves an unknown number of hops: who is connected to whom through a chain of shared attributes, or what’s the shortest path between two entities across a messy web of intermediaries. Each additional hop means another join, and performance degrades fast as the chain grows.
Graph databases are built around exactly that kind of traversal, which is why Microsoft added one directly into Fabric instead of leaving it to a bolt-on tool outside your governance boundary.
Think of a Subway Map
A subway system stores two basic kinds of facts: stations and the lines that connect them. If you ask which line a station is on, that’s a lookup. If you ask how to get from one station to another three transfers away, across lines you’ve never combined before, that’s a completely different kind of question. You’re not looking up a fact anymore. You’re tracing a path through a network.
A relational model answers the first question easily and the second one painfully, usually with a chain of self-joins that gets slower with every extra transfer. A graph treats the whole map, stations and connections alike, as the thing you’re querying, so tracing a path is a natural operation instead of a workaround.
Who Actually Uses It
- Business users can visually explore relationships and run natural language queries without writing GQL by hand
- Data engineers define graph models and unify data from OneLake using low and no-code tools
- Data scientists apply graph algorithms and machine learning directly against the graph for deeper pattern detection
Graph-Powered AI Reasoning
Fabric Data Agent can use graph as a data source, which is currently in preview. Once connected, people can ask natural language questions and the agent answers by traversing the graph instead of guessing at joins. That’s especially useful for multi-hop question answering, the kind of question where the answer depends on following several connections in sequence rather than pulling one row out of one table.
Where This Fits Next to Ontology
Graph is one of several components under Fabric IQ, alongside ontology, Fabric Data Agent, an Operations Agent, and Power BI semantic models. If ontology defines the shared business vocabulary, the entity types, properties, and rules that make data mean the same thing across teams, graph is closer to the query engine underneath, built specifically to traverse the relationships between those entities at scale. You can use graph on its own for relationship analysis, but the two are clearly designed to work together as Fabric IQ matures.
What It Costs to Run
Graph is billed on CPU uptime, with each second of active use costing capacity units, rounded up to the minute. Storage is provisioned at a minimum of 100 GB and billed at the same rate as OneLake cache. Both show up as separate line items in the Fabric Capacity Metrics app, so usage doesn’t get buried inside a general compute number. Availability is also regional, so it’s worth checking whether your tenant’s home region supports it before you plan a project around it.
Why It Matters
Most organizations already have the data needed to answer their hardest relationship questions. What they usually lack is a practical way to ask those questions without a data engineer spending a week hand-building a chain of joins that breaks the moment the schema shifts. Putting a graph engine directly inside Fabric, on top of data that’s already there, removes a lot of that friction.
As Fabric IQ fills out and graph, ontology, and Fabric’s AI agents start leaning on each other more directly, the organizations that get real value won’t be the ones with the most data. They’ll be the ones who can actually see how their data connects.