Subscribe
Share
Share
Embed
Graph in Fabric materializes a second copy of your data for traversal. That copy explains the staleness, the rebuild cycle, and the workspace boundary that decides whether graph belongs in your architecture.
Episode 35 • 2026-08-28 Duration: 8:42
Graph in Fabric materializes a second copy of your data for traversal. That copy explains the staleness, the rebuild cycle, and the workspace boundary that decides whether graph belongs in your architecture.
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.
The Snapshot Locked in a Room
Episode 35 | 2026-08-28
Fabric Architecture Podcast | Hosted by Matthias Falland with AI co-host Fabia
---
[00:08] Fabia: Three minutes. Two tables, one edge, and the graph refused every query for three minutes.
[00:13] Matthias: What was it doing?
[00:15] Fabia: Building. And until it finished, every request came back with 'graph not queryable.'
[00:20] Matthias: So what's it building, and what does that cost you?
[00:24] Fabia: That's the episode. One mechanism explains every friction in this feature, every ceiling, and one constraint that decides whether graph belongs in your architecture at all.
[00:35] Matthias: Walk me through it. What does Fabric actually build when I save a graph model?
[00:40] Fabia: Fabric reads your lakehouse tables and constructs a read-optimized structure for traversal. A second copy of your data, in separate storage, sitting next to your tables.
[00:52] Matthias: That three minutes in the demo — that was a tiny dataset?
[00:55] Fabia: Two tables. The ingestion job measured about a hundred seventy-eight seconds. Builds scale with data volume.
[01:03] Matthias: Why not just query the Parquet directly?
[01:05] Fabia: Parquet scans many rows of few columns. A graph query does the reverse — follows a handful of links, several hops deep, in an order only known at query time. In SQL, 'customers who bought what similar customers bought' is a stack of self-joins. Each hop adds another. In the graph, each hop follows a link that's already materialized.
[01:28] Matthias: So the copy isn't overhead... it IS the performance argument.
[01:32] Fabia: And the price is staleness. Add a row to the lakehouse, the graph doesn't know about it until the next save.
[01:39] Matthias: Can you patch the schema? Add a property, rename a node?
[01:43] Fabia: Schema evolution isn't supported. Any structural change means Fabric reloads all the data and rebuilds from scratch.
[01:50] Matthias: Every change is a full rebuild. That sets the whole rhythm.
[01:54] Matthias: What I keep running into is teams that hear 'graph database' and assume it replaces their warehouse. It sits beside it. The lakehouse keeps doing what it was doing.
[02:05] Fabia: The source data stays in OneLake. The graph reads it, copies it, and offers a different query surface on top.
[02:13] Fabia: Four query surfaces, one engine underneath. A visual builder, a GQL code editor, REST in beta, and natural language through Data Agent in preview.
[02:22] Matthias: Which one matters for the architecture record?
[02:25] Fabia: GQL. ISO/IEC 39075, the first new ISO query language since SQL. It came from the same ISO working group. What your team learns is portable.
[02:35] Matthias: Show me what the syntax looks like.
[02:37] Fabia: MATCH Customer, who purchases, Order. The relationship has a name, a direction, and it's the subject of the query. In SQL, that same thing is a join condition. Here it's the point.
[02:49] Matthias: Quick aside — this is Graph in Fabric. Last week was API for GraphQL. People mix them up.
[02:55] Fabia: Completely unrelated features that share a word. GraphQL is an API query language. This is a graph data model. And Microsoft Graph is the 365 API. Three things called Graph in the same building.
[03:08] Matthias: Three Graphs, zero overlap.
[03:10] Fabia: Someone asked. How much can I get back from one query?
[03:14] Matthias: I'd assume... a lot? It's a traversal engine.
[03:17] Fabia: Graph truncates responses when the internal representation exceeds sixty-four megabytes. You get the rows that fit, a warning in the response status, and no continuation token.
[03:29] Matthias: Truncates — with a warning? So if I'm not checking the status...
[03:33] Fabia: You've got a partial answer that looks complete.
[03:36] Matthias: That's worse than a hard error.
[03:39] Fabia: And intermediate results hit a hard cap at a hundred twenty-eight megabytes, so plan your GROUP BY around it.
[03:46] Matthias: So every saved query needs a bound. FILTER, LIMIT, GROUP BY. If a queryset gets shared, someone downstream is going to trust whatever comes back.
[03:56] Fabia: Which connects to what happens when the model changes.
[03:59] Matthias: I watched the demo — changed the model, opened the queryset, the new node type just wasn't there.
[04:06] Fabia: A queryset binds to the snapshot that existed when it was created. Save the model, Fabric builds a new snapshot. But the existing queryset still points at the old one.
[04:17] Matthias: Where's the refresh?
[04:18] Fabia: There isn't one. Create a new queryset.
[04:21] Matthias: Replace it? Every time? That's not going to happen in practice.
[04:25] Fabia: And yet that's the documented behavior. A queryset isn't stale in the way you're thinking — it's running against the snapshot it was made on. A photograph of the graph at one moment. The photograph isn't wrong because the scene changed.
[04:41] Matthias: Fine, but if I click create too early—
[04:43] Fabia: —you bind to a snapshot that isn't finished. And corruption can spread. Microsoft's documentation says queryset corruption can affect every queryset in the workspace, until a full browser refresh.
[04:56] Matthias: Not a tab refresh. A full browser refresh.
[04:59] Fabia: Graph sharing works one way. You share the item with named people in the Fabric UI, and they need the underlying graph model shared with them before a query runs. But there's no app, no embed, and no programmatic endpoint for external applications.
[05:16] Matthias: So I can't point Power BI at it. Can't build an app on top—
[05:20] Fabia: —the only programmatic path is the GQL query API, still in beta.
[05:24] Matthias: I'd call that a placement decision. Graph today is an analysis surface for the team that owns the data. You explore your own relationships in your own workspace. If the plan is to hand results to a broader audience, the architecture needs a different last mile.
[05:42] Fabia: On capacity. F2 or higher, and it's region-gated. Check availability before you promise anything.
[05:48] Matthias: What does it actually cost to run?
[05:51] Fabia: Compute time during builds and queries. Between them, the graph data sits in OneLake storage. You're not paying capacity units for a graph at rest. The cost concentrates around the rebuild schedule.
[06:04] Matthias: The irony is the rebuild costs the most, and it's the thing you do most when the schema keeps changing.
[06:11] Fabia: Which is why the advice is to stabilize your schema in the lakehouse first. Model the nodes and edges before you build. Each experimental rebuild burns your F2 minutes.
[06:22] Matthias: Steel-man for staying in SQL.
[06:24] Fabia: When the question is one hop — customer joined to orders, filtered, aggregated — SQL handles it fine. You skip the build, the staleness, and the workspace lock. If your hardest question is two tables and a WHERE clause, graph adds overhead for no return.
[06:41] Matthias: That's fair. Graph earns its keep at multi-hop, where the joins start compounding.
[06:46] Fabia: Even then, bound the depth. The visual path builder caps variable-length patterns at eight hops. In the code editor you can go further with bounded quantifiers, but each extra hop can still explode path count exponentially.
[07:01] Matthias: The risk I'd... actually lose sleep over isn't the build time. It's someone saving a deep traversal into a queryset, getting back sixty-three megabytes of a sixty-five megabyte answer, and making a decision on partial data.
[07:16] Fabia: Builds take real time on a large graph, so they belong on a schedule, not on someone's click.
[07:22] Matthias: Size the model lean. Nodes and edges start with no properties — keep it that way unless you'll actually traverse the column. Every property you add counts against roughly two billion elements.
[07:35] Fabia: A query timeout of twenty minutes. That's a ceiling you can plan around.
[07:40] Matthias: What you can't plan around is the copy. It's stale between rebuilds, locked to the workspace, and if you query it carelessly it hands you a partial answer with a warning you didn't read. Accept those three things and it solves relationship questions SQL can't touch. Reject any one of them and you need a different architecture.
[08:02] Fabia: Pattern dictates platform.
[08:04] Matthias: And somewhere right now, there's a queryset returning a result that was true yesterday.
[08:10] Fabia: The question is whether anyone checked the response status.
[08:14] Matthias: Find me on LinkedIn — Matthias Falland. DM me, I'd love to hear what you're building with this.
[08:20] Fabia: Check your region first.
---
End of episode. ~08:21 estimated.