Graph in Fabric: When Relationships Beat the Star Schema
Take a question from settlement operations: an agent bank invoice lands with a fee line that looks off, and someone has to trace it back through the clearing chain to the trades that generated the charge. Trade to settlement instruction, instruction to agent, agent to CSD, CSD to invoice line. In a dimensional model every one of those hops is a join, often through a bridge table, and the query that walks all of them is slow to run and slower to debug. Questions like this are not aggregation problems. They are path problems, and the star schema was never built for them.
Microsoft now has a first-party answer to that gap: Graph in Fabric reached general availability this month as part of the Build 2026 announcement wave, putting a native graph engine inside the platform where more and more finance data already lives.
What actually shipped
Graph in Fabric is a graph engine that operates directly on data in OneLake, so there is no separate graph database to provision and no extra data movement to keep in sync. The architecture is distributed and sharded, sized for graphs with billions of relationships. Queries are written in GQL, the ISO/IEC 39075 standard for graph query languages, with pattern matching, path traversal and aggregations, and Microsoft emphasizes portability across GQL-compliant systems. A natural-language layer, NL2GQL, lets non-technical users ask connection questions without learning the syntax. The engine also inherits Fabric's existing OneLake governance: the same RBAC, lineage tracking and compliance standards that already apply to the rest of the estate.
The release is positioned as the execution layer of Fabric IQ. Above the raw graph sits Ontology, where you define shared business vocabulary (entities, rules, constraints), so AI agents query an explicitly modeled view of the business instead of guessing structure from table and column names.
Where the star schema runs out of road
Dimensional modeling has earned its place, and nothing here changes that. For slicing expenses by cost center, computing variance against budget, or rolling results up an organizational hierarchy, a star schema plus DAX remains the right tool. An activity-based expense allocation model, distributing settlement costs to cost centers by trading activity, needs nothing a graph engine offers.
The strain appears when the question is about how things connect rather than how they sum. Reconciliation makes this vivid: the platform I worked on at Morgan Stanley matched 500K+ daily settlements against third-party agent and CSD invoices, and while the matching itself is tabular, investigating a break never is. You start from a suspect invoice line and walk backwards: which charge, booked by which agent, against which settlement, for which trade, under which fee arrangement. Every hop is a self-join or a bridge table, the depth varies from case to case, and SQL makes you fix the number of hops before you can even ask the question. Intercompany flows have the same shape, as do duplicate-vendor networks in accounts payable and dependency questions inside a lakehouse. The data is relational in the everyday sense of the word, and the storage model keeps refusing to admit it.
Graph databases have handled this class of problem for years. What is new is having one inside the platform, under the same governance, next to the data it describes.
When each model wins
The honest framing is not graph versus star schema but graph alongside it. A rough decision guide:
| Question shape | Typical finance example | Better fit |
|---|---|---|
| Aggregate by known dimensions | Expenses by cost center and month | Star schema |
| Fixed one- or two-hop lookup | Invoice line to vendor master attributes | Star schema |
| Variable-depth traversal | Fee on an invoice line back to originating trades | Graph |
| Dependency and impact analysis | Which reports break if this table changes | Graph |
| Connection discovery | Accounts linked through shared intermediaries | Graph |
Microsoft's own decision scenarios in the announcement run along the same lines: supply chain networks, fraud investigation, customer intelligence, and ontologies as the relational backbone for AI agents.
What a path query looks like
The fraud scenario in the announcement is the most transferable one for finance teams: an investigator starts from a flagged account and traces how funds move across intermediary accounts to downstream institutions, finding mule networks that stay invisible when transactions are analyzed one at a time. Swap the nouns and you have settlement-expense traceability. The shape of such a query, sketched in GQL (familiar territory for anyone who has written Cypher):
The syntax matters less than the primitive: variable-depth traversal is built in, rather than something you simulate with a recursive CTE and hope the optimizer cooperates. The NL2GQL layer aims one level higher, but the more consequential detail is how Microsoft frames agent access: agents execute deterministic queries over explicitly modeled relationships instead of inferring structure probabilistically. For anyone who has to defend a number to audit, a query whose path can be inspected is a materially better artifact than a similarity score.
Governance is the quiet headline
Standing up a separate graph database has always carried a hidden price in a regulated environment: a second security model, a second access-review cycle, and a gap in the lineage story. Graph in Fabric inherits OneLake's governance instead, with one security model across all the data. In my Fabric work at Syngenta, the engineering hours go disproportionately into exactly this layer (row-level security, data quality standards, CI/CD for BI assets), so an engine that arrives already inside that perimeter removes the objection that usually ends graph conversations in week one.
Scale evidence comes from inside Microsoft itself: Sentinel uses the graph engine to model security dependencies and reason over hundreds of millions of connected entities, tracing blast radius across multiple hops. An identity-to-tenant-to-policy chain is structurally not far from a trade-to-settlement-to-invoice chain.
What I would pilot first
A sensible pilot is one investigation-shaped problem, not a reporting rebuild. Candidates from the finance back office: tracing reconciliation breaks across a settlement chain, mapping intercompany flows, checking vendor networks in accounts payable for duplicates, or dependency analysis across a lakehouse before a refactor. Keep management reporting on the semantic model where it belongs, and treat early NL2GQL output the way you would treat a new analyst's first queries: useful, but checked.
The full announcement, Graph in Fabric (Generally Available), links tutorials, docs, a learning path and a recent webinar if you want to evaluate it hands-on.
General availability matters here mostly as a permission slip. Plenty of finance teams will have looked at graph capabilities in preview and concluded, reasonably, that month-end infrastructure does not run on previews. That excuse is now gone; whether the path-shaped questions in your operation are painful enough to justify a pilot is a judgment only you can make.
Facing a similar challenge?
📅 Book a Free Call