Episode Details

Most organizations believe modern platforms like Microsoft Fabric made T‑SQL optional. On the surface, pipelines run, reports refresh, and stakeholders see charts — so it is easy to conclude that SQL has become just one of many implementation details. But in reality, T‑SQL did not disappear. It moved upstream, into the layer where cost overruns, performance incidents, security drift, and audit findings are created long before anyone notices them in Power BI.

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 be