Subscribe
Share
Share
Embed
Fabric generates a GraphQL API from your warehouse in under a minute. But the connectivity dialog you see once decides your security posture, your RLS enforcement, and whether your production deployment silently reads development data. We trace the consequences.
Episode 34 • 2026-08-21 Duration: 10:47
Fabric generates a GraphQL API from your warehouse in under a minute. But the connectivity dialog you see once decides your security posture, your RLS enforcement, and whether your production deployment silently reads development data. We trace the consequences.
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 Radio Button That Sets Your Security Architecture
Episode 34 | 2026-08-21
Fabric Architecture Podcast | Hosted by Matthias Falland with AI co-host Fabia
---
[00:08] Fabia: Fabric generates a GraphQL API from your warehouse in under a minute. Schema, resolvers, Entra authentication, an endpoint your app team can call tonight.
[00:18] Matthias: And what's that API doing six months from now, when the table underneath it has three new columns nobody told it about?
[00:26] Fabia: The same thing it was doing on day one. Exactly the same thing.
[00:30] Matthias: So we're talking about an API that Fabric builds for you — and then stops watching. Today we figure out what 'generated' actually costs when nobody's maintaining the schema.
[00:41] Fabia: Here's what Fabric actually does. It reads your data source's schema and generates a complete, authenticated GraphQL endpoint from that single read. Resolvers included, Entra authentication wired in, no deployment, no backend you maintain. The entire API surface comes from one snapshot of your source's metadata. And that word 'snapshot' carries all the weight in this episode.
[01:07] Matthias: What happens when I need logic that isn't just 'read this table, write that row'?
[01:12] Fabia: You write a stored procedure in the data source and expose it through the API. That's the documented path — there are no custom resolvers, Fabric generates them and you don't get to edit them. But the stored procedure route costs you something. Those entities lose pagination, ordering, and filtering entirely. You get your business logic, you give up the query ergonomics that made the generated API attractive in the first place.
[01:41] Matthias: So the escape hatch is a crawl space.
[01:43] Fabia: Before any of that matters, there's a dialog you see exactly once. When you attach your first data source, you pick between two connectivity modes — SSO or saved credentials. And the enforcement clause from the docs is blunt: once selected, these options apply to every data source added to this API afterwards. You can't mix them.
[02:05] Matthias: — every source I add later is locked to that first choice?
[02:09] Fabia: Every one. And that choice decides more than how you authenticate. With SSO, the caller's own identity passes through to the data source — row-level security applies, per-user policies apply, the warehouse sees who's asking. With saved credentials, one shared connection does all the work. Your API users never touch the data source directly, which sounds like clean isolation until you realise every caller sees the same rows regardless of who they are.
[02:39] Matthias: Two completely different security postures, same radio button.
[02:44] Fabia: The limits tell you what this is for. A hundred items per page by default, a hundred-second request timeout. Those numbers describe an application screen — a product list, a customer record, an order history. If your answer to 'how much data' is 'all of it,' the answer to 'which feature' is a pipeline. Show me the query pattern, and I'll tell you whether this is the right tool.
[03:09] Matthias: Yeah — what I keep running into is teams that hear 'data API' and think 'export endpoint.' They point a batch job at it, paginate through fifty thousand rows, hit the timeout —
[03:21] Fabia: — because the API inherits the data source's query performance. A missing index on the warehouse becomes a slow GraphQL response, and no amount of tuning at the API layer fixes a table scan underneath.
[03:34] Matthias: And then they file a ticket saying the API is slow, when the real answer is they're asking a conversation endpoint to do a pipeline's job.
[03:43] Fabia: A question from the Fabric community that lands right here. 'I added columns to the table, updated the schema, and they are not there.'
[03:53] Matthias: Every time someone tells me their GraphQL API doesn't match their table, the first question is whether they added a column or added a table. Because those are different operations as far as the refresh is concerned.
[04:08] Fabia: The community thread confirms exactly that. Fabric's schema refresh reliably picks up new objects — a new table, a new view — but new columns on a table that's already attached? Inconsistent. The schema was captured when the API was created or last refreshed, and Update Schema in the portal doesn't always re-read an existing object's column list.
[04:31] Matthias: So the fix is remove the table from the API and re-add it.
[04:35] Fabia: That forces a fresh schema discovery on that specific object. The community thread also documents a workaround — attaching a different table triggers a broader refresh that picks up the missing columns as a side effect. It works, but it tells you something about how the refresh is scoped internally.
[04:55] Matthias: Adding a thing refreshes. Changing a thing doesn't. And if your mental model is 'this API tracks my table,' this is where that model falls apart.
[05:05] Fabia: Now carry that schema behaviour forward to deployment. API for GraphQL is Git-integrated, deployment pipelines are generally available — that part's real. But autobinding, where a deployed API automatically connects to the target environment's data source, needs two things to be true. SSO, and the data source in the same workspace. And there's a third case that catches people. If the API points at a SQL analytics endpoint that belongs to a lakehouse, autobinding doesn't happen even on SSO. The deployed API keeps reading the source workspace.
[05:41] Matthias: And with saved credentials?
[05:43] Fabia: The deployed API stays connected to the source workspace's data source. The credential is valid. The query returns rows. Nothing fails.
[05:52] Matthias: I need to say that slowly, because it's the worst class of defect in this entire conversation. Your production API is live, authenticated, serving real traffic — and the data is from your development warehouse. There's no error. There's no warning. A successful query is the thing that's lying to you. And the root cause is a radio button someone chose weeks or months earlier in a connectivity dialog.
[06:19] Fabia: The security posture and the RLS enforcement, you can reason about those up front. The deployment binding is the one that ambushes you, because the system doesn't distinguish between 'correctly deployed' and 'pointing at the wrong warehouse.' Both return rows.
[06:37] Matthias: Let's talk about what this costs to operate. The API doesn't carry its own SKU, it runs on whatever capacity the workspace has. But it does carry its own meter. And it just gave fifty app developers a way to query your warehouse, and they don't know they're consuming capacity units because they've never seen the warehouse.
[06:58] Fabia: Two meters, actually. API for GraphQL bills resolver execution time at ten capacity units an hour, on its own invoice line, and the warehouse underneath bills separately for the same request. And if that warehouse is sitting on an F64, the capacity behind it is a serious monthly commitment — and what it actually costs depends on your region and your reservation, so look it up rather than take a number from me. The sharper detail is that GraphQL requests count as interactive, smoothed over about five minutes, where warehouse queries get twenty-four hours. Fifty concurrent users paginating through product lists don't just cost more than three analysts writing T-SQL. They throttle sooner.
[07:44] Matthias: And look — saved credentials are genuinely the right answer in a real set of cases. When you've got an Azure SQL database behind a firewall that your app team shouldn't touch directly, and you deliberately want one permission surface instead of per-consumer data-source grants — saved credentials give you exactly the isolation you want. The tradeoff is you own the deployment verification yourself. That's a fair trade if you know you're making it.
[08:14] Fabia: One more thing worth knowing. The same properties that make GraphQL work well for applications — typed, self-describing, introspectable — also make it unusually suited for AI agents. Microsoft's documented a path to expose these APIs through a local MCP server authenticated by a service principal. An agent can discover what it's allowed to ask without anyone writing a tool definition by hand.
[08:41] Matthias: — which means the schema-drift problem we've been circling for ten minutes now applies to whatever your agents are reading too. Pattern dictates platform. And the pattern here says: write the connectivity decision into your architecture document, with the reason, before anyone opens the portal. The person debugging the deployment six months from now won't know a radio button caused it unless someone left a note.
[09:09] Fabia: Somewhere right now there's a GraphQL API returning clean JSON, passing every health check, serving an app that went live last quarter — and the table it's describing hasn't looked like that since May.
[09:23] Matthias: If that made something click — DM me on LinkedIn, find me as Matthias Falland.
[09:28] Fabia: Check your autobinding before you check your messages.
---
End of episode. ~09:32 estimated.