Beyond SELECT in Microsoft Fabric: Why T‑SQL Still Controls Cost, Performance, and Governance in Modern Data Platforms

In this episode of M365.FM, Mirko Peters examines why treating T‑SQL as “just query syntax” consistently produces fragile Fabric estates — and why the organizations that win with Microsoft Fabric treat T‑SQL as a contract language for their data platform. This is a conversation about the structural difference between writing queries and designing contracts, between debugging slow reports and engineering predictable execution plans, and between using Fabric as a convenient data lake and using warehouses, views, and procedures as enforcement zones for truth, access, and cost.

The organizations that will lead their industries are not those that wrote the most SQL, but those that use T‑SQL to make their platform deterministic. They centralize logic in views and procedures instead of scattering it across Power BI, notebooks, and apps. They treat execution plans as governance artifacts, not just troubleshooting tools. And they accept that in Fabric, every unmanaged “SELECT *” and every vague join is not just a technical shortcut — it is an unapproved commitment of cost, performance risk, and security exposure.

WHAT YOU WILL LEARN

• Why “Beyond SELECT” is about responsibility, not features — and why modern data stacks that optimize for convenience without contracts drift into non‑deterministic behavior.
• How SQL actually executes under the hood, and why understanding execution order and plans matters more in Fabric where shared capacity turns bad patterns directly into cloud bills.
• How to read execution plans as early warning signals for cost and risk: scanned vs returned rows, spills, joins, sorts, and why “it works” is not the same as “it’s safe to standardize.”
• How schema‑on‑read and raw Lakehouse tables become Warehouse liabilities when you don’t enforce constraints, contracts, and validation at the boundary.
• Why parameter sniffing and plan caching create “random” performance and cost spikes — and what trade‑offs exist between recompilation, general plans, and branching logic.
• How missing database‑layer permissions turn workspace roles into security debt, and why least privilege in Fabric still begins with T‑SQL roles, grants, and denies.
• When indexing, partitioning, and structural redesign matter more than query tuning — and how to recognize system‑shape problems posing as SQL problems.
• Why Copilot‑generated SQL accelerates both good and bad patterns, and how execution plans can become acceptance tests for AI‑written queries.

T‑SQL in Microsoft Fabric is not primarily about retrieving data. It is about enforcing intent. Every query and every object either makes your platform more deterministic (same question, same answer, within known cost and latency) or more probabilistic (sometimes fast, sometimes slow, sometimes cheap, sometimes expensive, sometimes correct, sometimes “close enough”).Mirko argues that Fabric did not remove the need for relational thinking — it removed the friction that used to slow bad decisions down. When a single workspace, shared capacity, and Copilot can push new SQL into production paths at refresh speed, your only real defense against entropy is to move contracts, governance, and enforcement into the same engine that now runs everything. T‑SQL is still the control surface where shape, access, and cost become enforceable — or where they are quietly left to chance.

WHO THIS EPISODE IS FOR

• Data engineering leaders and tech leads working with Microsoft Fabric, Warehouses, and Lakehouses.
• SQL and Fabric developers who feel their queries “work” but see unpredictable performance and cloud cost.
• Power BI and Fabric architects responsible for shared capacities, semantic models, and governed query surfaces.
• Platform, security, and governance teams who need to turn T‑SQL and execution plans into part of their control story, not just their troubleshooting toolkit.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365–6704921/support.

If this clashes with how you’ve seen it play out, I’m always curious. I use LinkedIn for the back-and-forth.