Skip to main content

plan-antipatterns

Fabric-specific adoption plan antipatterns​

While many cloud adoption antipatterns apply generally, Microsoft Fabric introduces a unique platform architecture and SaaS operating model that give rise to additional antipatterns. These missteps can derail adoption, cause friction across teams, or lead to inefficient cost and governance outcomes.

Antipattern: Treat Fabric like a traditional IaaS or PaaS platform​

Issue: Teams with deep Azure or traditional cloud experience often try to apply infrastructure-centric patterns in Microsoft Fabric. This leads to confusion about capacities, workspaces, and data product boundaries.

Example: A data team defines a Fabric Lakehouse with a schema similar to an old SQL-based data warehouse but without considering workspace boundaries or capacity isolation. The result is performance bottlenecks and noisy neighbors due to resource contention.

Preferred outcome: Embrace the SaaS-native nature of Fabric. Design solutions around capacities, workspaces, and domain-aligned data products. Plan early for capacity scaling and isolation strategies.

Antipattern: Underestimate capacity planning and cost transparency​

Issue: Fabric’s consumption and cost model is based on capacity units (CU), not per-user or per-workload billing. Teams that don't factor in usage patterns risk cost surprises or slowdowns.

Example: Multiple teams share a single capacity without workload scheduling or governance. During peak usage, mission-critical reports fail due to CPU throttling, causing business disruption.

Preferred outcome: Establish clear capacity ownership models. Use dedicated or pooled capacities strategically. Monitor CU consumption with Microsoft Fabric Admin APIs and Cost Management tools.

Antipattern: Ignore OneLake architectural principles​

Issue: OneLake is a central data lake built on a single copy principle. Treating it like a traditional storage service with redundant exports or unmanaged layers can break its benefits.

Example: Teams export Lakehouse tables to Azure Data Lake Gen2 for external processing, introducing redundancy, governance complexity, and higher costs.

Preferred outcome: Leverage shortcuts and data sharing across workspaces to avoid duplication. Centralize schema definitions and use fine-grained access policies in OneLake.

Antipattern: Delay security and governance planning​

Issue: Fabric allows rapid adoption via Power BI or self-service workloads. Without governance boundaries, security gaps and data sprawl emerge.

Example: Business units create Fabric workspaces with public links and unmonitored sharing of semantic models, bypassing IT governance.

Preferred outcome: Implement workspace templates, DLP policies, and role-based access early. Establish governance tiers for sandbox, development, and production environments.

Antipattern: Use the wrong Fabric "house" for the wrong purpose​

Issue: Fabric provides several "houses" (Lakehouse, Warehouse, Eventhouse, KQL Database), each optimized for different workloads. Misusing these leads to poor performance or high cost.

Example: A team stores semi-structured IoT data in a Fabric Warehouse instead of Eventhouse or KQL Database, resulting in slow queries and excessive storage costs.

Preferred outcome: Choose the right storage and processing engine based on data type, latency, query complexity, and user experience needs.

Antipattern: Skip CI/CD and automation​

Issue: Manual deployment of Fabric artifacts (like dataflows, pipelines, semantic models) leads to inconsistencies and loss of auditability.

Example: A team manually deploys Power BI semantic models into production, bypassing QA and leading to broken reports.

Preferred outcome: Use deployment pipelines, Git integration, and YAML-based CI/CD to manage Fabric artifacts as code. Standardize promotion paths and version control.

Antipattern: Fragment metadata and lineage​

Issue: Siloed data models, disconnected semantic models, and undocumented transformations make troubleshooting and compliance difficult.

Example: A business report is built on a dataflow that transforms OneLake tables, but no one can trace the lineage across workspaces.

Preferred outcome: Use Fabric's built-in lineage view, standardize naming conventions, and document transformations. Integrate Microsoft Purview for cross-platform data cataloging.

Contributors