Microsoft Fabric architecture decisions made early in a deployment determine whether the platform scales well or accumulates technical debt. Organizations that design OneLake structure, medallion layers, and governance controls deliberately from the start spend significantly less time cleaning up problems later. Those that skip the architecture phase and experiment directly in production tend to hit the same set of avoidable issues: duplicate data, ungoverned workspaces, semantic model inconsistencies, and Direct Lake performance problems that trace back to table design.
This post covers the structural decisions that define a production-grade Microsoft Fabric architecture.
Key takeaways
- A production-grade Microsoft Fabric architecture is decided by four things: how OneLake and workspaces are organized, how the medallion layers are separated, how Direct Lake tables are designed, and how Microsoft Purview governs the whole tenant.
- Put bronze, silver, and gold in distinct Lakehouses and ideally distinct workspaces. Bronze holds unmodified source data and is often the most sensitive; gold is the most widely consumed.
- Check the workspace Spark resource profile before you diagnose a Direct Lake performance problem. New workspaces default to writeHeavy, which turns V-order off.
- Sensitivity labels and lineage applied at the data layer carry through to every Power BI report and AI workload built on top, which is what makes compliance documentation possible.
- The same governed gold layer that feeds analytics feeds AI, so architecture quality pays off across every workload at once rather than once per project.
OneLake as the Foundation of a Microsoft Fabric Architecture
OneLake is the single storage layer that sits beneath Microsoft Fabric. Lakehouses and Warehouses write their tables there as Delta Parquet, Eventhouses can expose their Kusto Query Language (KQL) data there once OneLake availability is enabled, and Direct Lake semantic models read from it rather than holding a separate copy. That shared foundation, which Microsoft documents OneLake as a single logical data lake for the whole tenant, is what makes cross-workload access possible without duplicating data between services.
The most important early decision in a Microsoft Fabric architecture is how to organize OneLake. This means deciding how workspaces map to business domains, how Lakehouses are scoped, and where data lives at each stage of the quality lifecycle.
A flat workspace structure creates governance problems quickly. A well-designed Fabric architecture uses workspaces as isolation boundaries: separate workspaces for data engineering, analytics, and AI workloads, with access controls applied at the workspace level rather than the item level wherever possible.
OneLake shortcuts deserve deliberate attention. They allow Fabric to reference data in Azure Data Lake Storage Gen2, Amazon S3, or other OneLake paths without copying it. This is useful for phased migrations and cross-domain data sharing, but a proliferation of shortcuts without clear ownership creates lineage gaps that are hard to resolve after the fact. Design your shortcut strategy with the same care as your ingestion pipelines.
The Medallion Architecture Inside Fabric
The medallion pattern, bronze for raw data, silver for cleaned and conformed data, and gold for curated analytics-ready data, is the standard structural pattern for Fabric Lakehouses. Microsoft recommends it, and Winmill applies it consistently across Fabric deployments.
In a Fabric context, the medallion layers should be physically separated. Bronze, silver, and gold belong in distinct Lakehouses, ideally in separate workspaces aligned to access requirements. Bronze data is often sensitive because it is unmodified source data. Gold data is broadly consumed. Conflating them in a single Lakehouse or workspace creates access control problems.
Each layer has specific engineering requirements:
The bronze layer should store data exactly as it arrived from the source, with no transformation. Schema enforcement at this layer creates fragility because source systems change without notice. Append-only storage with timestamps preserves the full history for reprocessing.
The silver layer applies business rules, removes duplicates, and enforces agreed schemas. This is where data quality checks run, and where downstream teams should be directed when they need reliable data without doing transformation work themselves.
The gold layer holds curated datasets built for specific consumption patterns: Power BI semantic models, AI feature stores, and data products served through an application programming interface (API). Gold tables should be designed for their specific use case, not as generic denormalized tables that serve everyone poorly.
Direct Lake and Semantic Model Design
Direct Lake is the Power BI mode that reads Delta Parquet files from OneLake directly into memory without a full dataset refresh. It delivers Import-mode query performance with near-real-time data freshness. For most Fabric deployments, Direct Lake is the target semantic model mode for gold-layer consumption.
Getting good performance out of Direct Lake requires specific table design choices.
Partition strategy matters. Date-based partitioning on large fact tables is the most common pattern. Poorly partitioned tables on large datasets produce slow cold-start behavior as Direct Lake pages columns into memory.
V-order optimization now needs an explicit decision, because the default changed. New workspaces default to the writeHeavy Spark resource profile, a change that landed in 2025, and writeHeavy sets V-order off. Data written to a Lakehouse through notebooks in those workspaces is not V-ordered unless you turn it on or move the workspace to the readHeavyForPBI profile. Check this before diagnosing a Direct Lake performance problem as a partitioning issue.
Because the resource profile is set per workspace, this is a further argument for separating the medallion layers. The writeHeavy default suits bronze and silver ingestion. The gold layer that Direct Lake semantic models read from belongs in a workspace tuned for reads.
Keep semantic models focused. A semantic model built on top of a gold-layer Lakehouse should represent a specific business domain, not a general-purpose warehouse. Wide models with hundreds of measures and complex many-to-many relationships are harder to maintain and produce slower Direct Lake behavior.
Across client deployments, the pattern that works consistently is a thin, well-governed gold layer feeding narrow, purpose-built semantic models. The Microsoft Fabric and Foundry page describes how Winmill structures these engagements.
If you are weighing a Fabric build and want a read on whether your current data foundation can carry it, our fit check asks three questions and takes about two minutes.
Governance with Microsoft Purview
Microsoft Purview is the governance layer for Fabric. It handles data classification, lineage tracking, sensitivity labels, and audit logging across the full Fabric tenant. For regulated industries and organizations preparing for compliance requirements, Purview integration is not optional.
Sensitivity labels applied at the data layer flow through to Power BI reports and AI workloads that consume that data. A dataset classified as confidential will carry that label into every downstream artifact, which controls who can see it and what export actions are permitted.
Data lineage tracked through Purview covers the path from source through bronze, silver, and gold layers to the semantic model and report. This lineage is essential for troubleshooting data quality issues and for the documentation requirements that high-risk AI workloads face under compliance frameworks like the EU AI Act.
Workspace governance in Fabric is enforced through Entra ID groups and Fabric workspace roles. Assigning access through groups rather than individual user assignments makes governance scalable as the team and the data estate grow.
For a detailed view of how Purview connects to the full Winmill governance approach, see the Responsible AI Guardrails on Azure post.
Fabric as the Foundation for AI Workloads
A well-designed Microsoft Fabric architecture supports AI workloads as a direct consequence of good data engineering, not as a separate project. The medallion structure that produces clean gold-layer data for Power BI produces equally clean training data for machine learning and grounded retrieval data for AI systems.
Microsoft Foundry and Azure Machine Learning both integrate directly with OneLake. AI agents and copilot features that retrieve enterprise data do so through the same governed Fabric layer that serves every other workload. Organizations that invest in Fabric architecture quality see the benefit multiplied across analytics, reporting, and AI simultaneously. Our post on building an enterprise AI strategy on Azure covers how to sequence those AI use cases once the foundation is in place.
How Winmill Designs Microsoft Fabric Architectures
Winmill’s Data and Intelligence practice designs Microsoft Fabric architectures that are ready for AI from the first deployment rather than retrofitted later. That covers OneLake and workspace structure, medallion layer design, Direct Lake and semantic model performance, and Purview governance.
We work with teams at the point where the structural decisions are still cheap to make, and with teams who need to restructure a tenant that grew faster than its architecture. If you are planning a Fabric deployment or working through performance and governance problems in an existing one, an AI Readiness Assessment from Winmill gives you a clear picture of the path forward.
Frequently asked questions
What is a Microsoft Fabric architecture?
A Microsoft Fabric architecture is the design of how OneLake storage, Lakehouses, Warehouses, workspaces, and semantic models are structured and governed within a Fabric tenant. It covers data organization across bronze, silver, and gold layers, workspace access controls, Direct Lake configuration, and Purview integration.
What is the medallion architecture in Microsoft Fabric?
The medallion architecture organizes Fabric Lakehouses into three layers: bronze stores raw source data unchanged, silver applies cleaning and business rules, and gold holds curated datasets built for specific analytics or AI consumption. Each layer should be in a separate Lakehouse with access controls appropriate to its sensitivity.
How does Direct Lake work in Microsoft Fabric?
Direct Lake reads Delta Parquet files from OneLake directly into Power BI memory without a full dataset refresh. It delivers Import-mode query speed with near-real-time freshness. Good Direct Lake performance requires well-partitioned gold-layer tables, V-order optimization, and focused semantic model design.
How does Microsoft Purview integrate with Fabric?
Purview provides sensitivity label enforcement, data lineage tracking from source to report, and audit logging across the Fabric tenant. Labels applied at the data layer carry through to Power BI reports and AI workloads. Lineage tracked through Purview supports compliance documentation requirements.
Why does Fabric architecture affect AI workloads?
The medallion structure that produces clean, governed gold-layer data for analytics produces the same quality data for AI training and retrieval. Microsoft Foundry and Azure Machine Learning integrate directly with OneLake, so a well-designed Fabric architecture improves AI output quality without additional data preparation work.
Keep reading
Building an Enterprise AI Strategy on Azure
AI strategy consulting has become one of the most requested conversations Winmill has with technical leaders.
Serverless Kubernetes on Azure Explained
Serverless Kubernetes on Azure describes a model where teams deploy containerized workloads without managing the underlying node infrastructure.
Building a Model Governance Framework on Azure
A model governance framework is what separates enterprise AI that organizations can defend to regulators, auditors, and boards from AI...