Subscribe
Share
Share
Embed
Graph in Fabric materialises a snapshot of your data's relationships the moment you save the model. That one decision explains the stale queryset, the failed-to-load error and the corruption right after a save. The 64 MB truncation is a separate limit, and it is the one nobody warns you about.
Episode 35 • 2026-08-28 Duration: 9:41
Graph in Fabric materialises a snapshot of your data's relationships the moment you save the model. That one decision explains the stale queryset, the failed-to-load error and the corruption right after a save. The 64 MB truncation is a separate limit, and it is the one nobody warns you about.
AI-generated voices. Matthias — cloned voice. Fabia — designed AI co-host. See Matthias live on YouTube (Fabric Friday), at his meetups, and at conferences like FabCon.
Hosted by Matthias Falland — Microsoft Data Platform MVP and community architect behind the Fabric Periodic Table. New episodes every Friday.
Have an architecture decision you are wrestling with? DM Matthias on LinkedIn — find him as Matthias Falland. Three to five sentences about the decision, your team size, and your current stack. We anonymize before airing.
This podcast was generated by AI. Both voices are synthetic: Matthias is a cloned voice, Fabia is a designed AI co-host.
Brand design based on fabricperiodictable.com.
Architecture decisions for Microsoft Fabric. Anonymized real customer scenarios, cost realism, counter-arguments included. Weekly episodes aligned with Fabric Friday recordings.
When Your Graph Query Lies to You
Episode 35 | 2026-08-28
Fabric Architecture Podcast | Hosted by Matthias Falland with AI co-host Fabia
---
[00:08] Fabia: You run a graph query in Fabric. Thirty thousand rows come back, clean columns, no errors. And the result is wrong.
[00:15] Matthias: Wrong how? The query ran.
[00:17] Fabia: It ran. And it truncated the answer at sixty-four megabytes without telling you. You got back everything that fit, and nothing that didn't.
[00:26] Matthias: So today — graph in Fabric. The feature that gives you a graph database inside your lakehouse. And there's one architectural decision underneath it that explains every rough edge people are reporting.
[00:40] Fabia: Graph in Fabric implements GQL — ISO/IEC 39075, widely regarded as the first new ISO database query language since SQL. Your team learns a portable standard here. And the syntax makes the relationship a first-class element of the query. MATCH customer purchases order — the relationship has a name and a direction, and it's the subject of the query. In SQL, that same question is a join condition buried in a WHERE clause.
[01:08] Matthias: So instead of writing three nested CTEs to chase a relationship chain, I write a path expression.
[01:14] Fabia: And there are four surfaces that all execute the same engine underneath. A visual query builder for exploration, the GQL code editor for anything repeatable, a REST API for automation, and a natural-language-to-GQL route through the Fabric Data Agent — still in preview.
[01:32] Matthias: That REST API is the one I'd actually care about in a production scenario.
[01:37] Fabia: Microsoft's architecture page says something most summaries skip past. When you save a graph model, Fabric ingests data from the underlying lakehouse tables and constructs a read-optimised, queryable graph. That's a separate, materialised, point-in-time structure. A snapshot.
[01:56] Matthias: Wait — every time I save, it's building a whole new copy of my data?
[02:00] Fabia: The entire thing. And there's a reason for it. Traversal and columnar storage want opposite things. Parquet scans many rows of few columns. A graph query follows a few pointers many hops deep, in an order that's only known at query time. You can't serve both from the same physical structure, so Fabric builds a second one, shaped for traversal.
[02:23] Matthias: And the price of that copy is staleness.
[02:26] Fabia: 'My queryset does not show the changes I made to the model.'
[02:30] Matthias: Sounds like a refresh button is missing somewhere.
[02:34] Fabia: It is missing, and Microsoft says so plainly. There's no UI option today to point an existing queryset at an updated model. A queryset binds to a snapshot. When you change the model and save, Fabric builds a new snapshot, but your existing querysets are still looking at the old one. The documented remedy is to create a new queryset altogether.
[02:57] Matthias: So every model change means throwing away my saved queries and rebuilding them from scratch?
[03:03] Fabia: Everything downstream of a snapshot is bound to the version it was created against. That includes every queryset that was built on the previous model.
[03:13] Matthias: That's a workflow cost most teams don't budget for. Every model iteration means a round trip through every downstream queryset.
[03:22] Matthias: Hang on. The tab-switching thing where the canvas empties — is that the snapshot too?
[03:28] Fabia: No. That one's a separate defect, a front-end problem with the multitasking UI, and Microsoft lists it on its own. But three of the four entries in that troubleshooting article are timing problems around the same thing. The queryable graph takes time to become ready, and the UI lets you act before it is. 'Failed to load graph model' — the snapshot's still building. Queryset corruption after a save — you created it before the new snapshot was done. And that corruption can affect every queryset in the workspace until you do a full browser refresh.
[04:05] Matthias: So the feature isn't flaky —
[04:06] Fabia: The product doesn't tell you it made a copy. Learn the snapshot and the feature is coherent. Miss it and you're debugging four separate defects that are actually one.
[04:17] Fabia: And that brings us back to the cold open. The sixty-four megabyte truncation is what happens when the query's result set outgrows the response buffer. The engine doesn't reject the query. It doesn't throw an error. It gives you back everything that fits and silently drops the rest.
[04:36] Matthias: API for GraphQL has a sixty-four meg limit too, doesn't it?
[04:40] Fabia: Different documented behaviour. API for GraphQL describes sixty-four megabytes as a maximum response size. Graph describes truncation. A ceiling is at least documented — you know it exists before you reach it. Truncation is a haircut — you walk away thinking you still have all your hair.
[04:59] Matthias: And the traversal depth?
[05:01] Fabia: Eight hops maximum on variable-length patterns. And that's worth sitting with, because variable-length traversal is the reason you came to a graph database. Each extra hop can increase evaluated paths exponentially in a dense graph. Traversal becomes expressible and comparatively cheap — that's the actual win. But unbounded, it's still combinatorics.
[05:24] Matthias: In an architecture review, I'd ask the access question before the modelling question. A graph in Fabric cannot leave its hosting workspace. There's no app, no share, no endpoint that carries it beyond that boundary. If the people who need the answer sit outside the workspace, graph is disqualified before the data modelling conversation even starts. And I keep seeing teams get weeks into a proof of concept before someone asks who's actually going to consume this thing.
[05:56] Fabia: The capacity floor is F2, but that's the entry ticket, not the running cost. Graph bills ten capacity-unit-seconds for every second of CPU uptime, and it provisions a hundred gigabytes of storage as a minimum, billed at OneLake cache rates. So the floor is F2 plus a storage line nobody chose. Ten models per workspace, region-gated availability — you need to verify your region before you promise anything — and no schema evolution, which means every structural change is a full reingest into a new model.
[06:30] Matthias: And in fairness, when the conditions line up, this is genuinely better than the alternative. I keep running into relationship queries that are three or four nested CTEs deep, and they still can't express a variable-length path. GQL makes that a one-liner. And it's an ISO standard, so what your team learns is portable beyond Fabric. The conditions are narrow, but they're real.
[06:55] Fabia: Workspace-internal analysis. Questions that are fundamentally about paths between entities. A team that can absorb the snapshot rebuild cycle into their workflow. Outside those conditions, a join answers the question and costs you less to maintain.
[07:12] Matthias: One more thing that keeps tripping people up. Last week was API for GraphQL. This week is Graph. Completely unrelated, and the names are close enough that people merge them in architecture meetings.
[07:25] Fabia: GraphQL is an API query language with nothing to do with graph data structures. Graph in Fabric is a data model with nothing to do with GraphQL. And neither of them is Microsoft Graph, which is the Microsoft 365 API.
[07:39] Matthias: Three products, zero overlap. Good luck with that steering committee.
[07:44] Fabia: Show me the query pattern. If the question is about paths between entities, and the audience is the team that owns the data, graph gives you something SQL genuinely cannot express. If the audience needs to leave the workspace, or if a join answers it, you're paying for a snapshot you don't need.
[08:04] Matthias: A graph in Fabric is a photograph of your data's relationships. Sharp when you take it. Useful for exactly as long as nothing moves. And the moment you change the model, every queryset in the workspace is still looking at yesterday.
[08:20] Fabia: If you've hit any of these edges — the truncation, the staleness, the naming confusion — we'd genuinely like to hear about it.
[08:28] Matthias: DM me on LinkedIn — find me as Matthias Falland.
[08:31] Fabia: See you next Friday.
---
End of episode. ~08:33 estimated.