TL;DR
Microsoft Fabric architecture is one SaaS platform where every workload reads and writes the same storage. That storage is OneLake, a single logical data lake per tenant. Nine workloads sit on top of it, from Data Factory through to Power BI and Fabric IQ. A shared platform layer underneath handles governance, security and Copilot. You buy compute once as a capacity, and every workload draws from it. Five decisions shape the design, covering capacity, region, workspace layout, semantics and recovery.
Key Takeaways OneLake is the architecture. Every Fabric workload reads and writes the same tenant-wide lake in Delta Parquet or Apache Iceberg, so the old copy-per-tool pattern disappears. The workload names changed. Microsoft retired the “Synapse” prefixes, and the current nine workloads now include Databases and Fabric IQ. Fabric IQ is the newest architectural layer. Ontology, semantic models, Fabric Graph and data agents now sit between your data and everything that consumes it. Capacity is the shared resource that decides everything. One F SKU feeds all workloads in a workspace, and bursting, smoothing and throttling govern what happens when demand spikes. Five reference patterns cover almost every enterprise build: lakehouse-first, warehouse-first, real-time-first, mirror-and-federate, and domain-aligned data mesh. Region and workspace decisions are the hard ones to reverse, so make them before the first pipeline ships, not after. Three Teams, Three Different Fabric Diagrams Picture the shortlist meeting. The platform team draws Fabric as a lakehouse with a medallion stack. The BI team draws it as Power BI with a better back end. The application team draws it as a place to mirror the order database so analytics stops hammering production. All three diagrams are correct, and that is the problem. Fabric is broad enough that everyone sees the part that solves their problem, and the architecture that ships is whichever team drew loudest.
An architecture that holds up needs a shared picture first, drawn with the names Microsoft actually uses today. For the release-by-release view of what shipped recently, our running log of Microsoft Fabric updates tracks that separately.
What Is Microsoft Fabric Architecture? Microsoft Fabric architecture is a software-as-a-service analytics platform built around one shared storage layer. You do not provision a lake, a warehouse, a streaming store and a BI service separately and then wire them together. You provision capacity, and every analytics engine inside Fabric already points at the same data.
Microsoft describes it as workloads sitting on a platform layer. The platform layer holds OneLake, Copilot and governance. The workloads are the specialised experiences a data team works in. Everything above the line changes depending on the job; everything below the line is constant. That single idea explains most of what makes Fabric different from the Azure stack it replaces.
The mental model worth carrying into every design conversation is short: one lake, many engines, one bill . One lake, because there is exactly one OneLake per tenant and workspaces are folders inside it. Many engines, because Spark, T-SQL, KQL and the Power BI engine all read that same storage without a copy step, which is what makes cloud analytics on one platform practical. One bill, because a single capacity feeds all of them, which means a runaway Spark job and a slow report are competing for the same pool.
What the SaaS Model Costs You Every architecture decision buys something and gives something up, and most Fabric write-ups skip the second half. The SaaS model removes infrastructure work: no clusters to size, no storage accounts to network, no version upgrades to schedule. What it removes in exchange is control. You cannot pin a Spark version indefinitely, you cannot place compute outside the capacity, and the region you pick at tenant and capacity creation constrains where data lives for a long time.
Teams coming from Apache Spark on infrastructure they tuned themselves feel this first. Teams coming from a Power BI Premium estate barely notice it, because they never had that control. If you are weighing the two platforms rather than the two eras, our Microsoft Fabric versus Databricks comparison goes deeper. Knowing which group you are in tells you how much of this guide is a change in tooling and how much is a change in operating model.
The Microsoft Fabric Architecture Diagram, Layer by Layer A Fabric diagram is only useful if it shows where data physically sits and where compute runs. The six-layer view below is the one we put in front of enterprise architecture boards, because it maps cleanly onto the decisions each group has to make.
Sources. Operational databases, SAP, Salesforce, files, event streams and anything else already in the estate. Nothing here belongs to Fabric, and a good architecture keeps it that way for as long as possible.
Ingestion. Four routes into the platform: Data Factory pipelines and Dataflows Gen2 for classic movement, mirroring for continuous replication, shortcuts for zero-copy references, and eventstreams for data in motion. Choosing between these is the most consequential early decision, and it gets its own section below.
Storage. OneLake. One logical lake for the whole tenant, organised into workspaces, holding lakehouses, warehouses and eventhouses. Tables are stored in Delta Parquet or Apache Iceberg, both open formats that outside tools can read directly.
Compute. The engines. Spark for Data Engineering and Data Science, a distributed T-SQL engine for the warehouse, KQL for Real-Time Intelligence, and the Power BI engine reading Delta tables through Direct Lake . They are separate engines with separate strengths reading one set of files.
Semantics. The layer that did not exist in the 2024 diagrams. Fabric IQ holds ontology, semantic models, Fabric Graph and the agents that read them. This is where a KPI gets one definition instead of fourteen.
Consumption. Power BI reports, data agents answering questions in natural language, Activator firing on conditions, and APIs serving applications.
Two bands cross all six layers rather than sitting inside one. Governance runs from source to report through Microsoft Purview, sensitivity labels, OneLake security and the OneLake catalog. Capacity is the compute and the cost envelope every layer draws from. Architects who draw these as boxes in a row instead of bands are usually the ones who discover a governance gap late.
Microsoft publishes its own end-to-end version of this in the Azure Architecture Center , staged as ingest, store, process and serve. It is worth reading alongside this one, with the caveat that the Architecture Center page trails the product documentation by a few months on naming.
What Are the Components of Microsoft Fabric Architecture? Microsoft currently ships nine workloads on the Fabric platform. If your internal documentation still says “Synapse Data Engineering” or “Synapse Data Warehouse”, it is describing a naming scheme Microsoft has retired. The current list, taken from Microsoft’s own Fabric overview documentation , is below with the question that should send you to each one.
Table 1: Microsoft Fabric components and when to reach for each one
Component What it does Reach for it when What it writes to OneLake OneLake The single logical lake for the tenant Always. It is not optional and there is one per tenant Delta Parquet and Iceberg tables, plus files Data Factory Pipelines, Dataflows Gen2 and 200-plus connectors You need scheduled movement or low-code shaping Tables and files in a lakehouse or warehouse Data Engineering Spark notebooks, jobs and lakehouse transformation Transformation logic outgrows a low-code tool Delta tables in a lakehouse Data Warehouse A distributed T-SQL engine with compute separated from storage The team writes SQL and needs multi-table transactions Delta tables, written by the warehouse engine Real-Time Intelligence Eventstream, Eventhouse, KQL, Real-Time hub and Activator for real-time analytics Data arrives continuously and staleness has a cost Eventhouse tables, queryable from OneLake Databases SQL database and Cosmos DB running natively inside FabricYou need a transactional store next to the analytics Automatically replicated as Delta tables Data Science Notebooks, experiments, MLflow tracking and model registry Predictions need to land back in the same lake Model artifacts and prediction tables Fabric IQ (preview)Ontology, planning, Fabric Graph, data agents and semantic models The same KPI means different things in different reports Semantic definitions over existing OneLake tables Power BI Semantic models, reports and Direct Lake Anyone outside the data team needs to see the result Reads directly; writes back through user data functions Industry Solutions Prebuilt data models for healthcare, retail and sustainability A regulated industry model would otherwise be built twice Industry-shaped tables in a lakehouse
Two clarifications save a lot of confusion. Fabric Data Factory shares concepts with Azure Data Factory but is a different service with a different runtime and different billing, so an existing Azure Data Factory estate does not simply appear in Fabric. And the lakehouse and the warehouse are not two names for one thing: the lakehouse is Spark-first with a read-only SQL analytics endpoint, while the warehouse is T-SQL-first and can write through SQL.
OneLake: The Storage Layer Under Every Workload OneLake is the part of Fabric architecture that earns the platform its name. There is exactly one per tenant, it is provisioned automatically, and it cannot be deleted. Workspaces are containers inside it, and items such as lakehouses and warehouses are folders inside those. Anyone who has managed a sprawl of storage accounts with inconsistent naming will recognise what this removes, and it is the clearest argument for a unified data platform .
Open Formats, and Why Iceberg Matters Now OneLake stores tables in Delta Parquet or Apache Iceberg , and it bridges the two through metadata virtualization. An Iceberg table can be read as a Delta table across Fabric workloads, and a Delta table can be read by an external Iceberg reader. For an enterprise running Snowflake alongside Fabric, that removes a whole category of synchronisation work, because both platforms can read the same physical files.
Shortcuts, Mirroring or a Copy This is where most Fabric architectures are decided, and where most of them go wrong. All three options make data appear in OneLake, and they behave very differently under load.
Shortcuts are pointers. The data stays in Amazon S3, Azure Data Lake Storage, Google Cloud Storage, Dataverse, SharePoint or another Fabric item, and OneLake references it with no copy. Intelligent caching keeps repeat reads local and reduces egress charges.Mirroring replicates continuously. Fabric keeps a near-live copy in OneLake as Delta tables, and your source system keeps serving its application without analytics queries landing on it.A copy through an ETL pipeline or Dataflow Gen2 is the right answer when you need to reshape data on the way in, apply business rules, or land history the source no longer keeps.Shortcut transformations now blur the line usefully. A shortcut pointed at CSV, Parquet or JSON files will convert them to Delta tables automatically, with no pipeline to build or maintain. That capability is generally available and it removes a surprising amount of boilerplate ingestion code.
Medallion Layering Inside OneLake Most Fabric builds organise the lakehouse into bronze, silver and gold layers: raw as landed, cleaned and conformed, then business-ready. Materialized lake views , generally available since March 2026, let you declare those layers in Spark SQL with dependency ordering, incremental refresh and data-quality constraints instead of hand-orchestrating notebooks. If you are still chaining notebooks to build a medallion stack, that is now the older way to do it.
How Data Gets Into Fabric: Pipelines, Mirroring and Shortcuts Ingestion is where a Fabric architecture either stays simple or quietly turns into the thing it replaced. The four routes below all end with data queryable in OneLake, and they differ on the three things that matter in a design review: whether bytes move, how fresh the result is, and how much you have to maintain.
Table 2: Choosing an ingestion route into OneLake
Route Do bytes move? Freshness Best fit Watch out for Shortcut No Live, read through to the source Cloud object storage you already own and trust Source outages become Fabric outages Mirroring Yes, continuously Near real time Operational databases you must not query directly Source-specific prerequisites, especially on-premises Pipeline or Dataflow Gen2 Yes, on a schedule As often as you run it Anything needing reshaping or business rules in flight This is the route that accumulates maintenance Eventstream Yes, as events arrive Seconds Telemetry, clickstream, IoT and application events Retention and cost grow with event volume
What Fabric Can Mirror Today The mirroring source list has roughly doubled over the past year, and it now covers most of what a large estate actually runs. Per Microsoft’s mirroring documentation , Fabric mirrors Azure SQL Database, Azure SQL Managed Instance, SQL Server, Azure Cosmos DB , Azure Database for PostgreSQL, Azure Database for MySQL in preview, Oracle, SAP, Snowflake, Google BigQuery, Azure Databricks, Dremio in preview, SharePoint lists in preview, and Fabric’s own SQL database.
There are now three kinds of mirroring, and confusing them leads to wrong capacity estimates. Database mirroring replicates whole databases and tables. Metadata mirroring, which is how Azure Databricks Unity Catalog and Dremio work, synchronises catalog structure and uses shortcuts underneath, so no data moves at all. Open mirroring lets a developer write change data into a mirrored database directly from an application.
On-premises SQL Server deserves a specific note because it trips up migration plans. SQL Server 2016 through 2022 mirror using change data capture. SQL Server 2025 uses a newer change feed and requires the instance to be connected through Azure Arc, and it is not supported on Azure virtual machines or on Linux. Check that before committing to a mirroring-based design for a legacy estate.
Fabric IQ: The Semantic Layer That Changed the Architecture Fabric IQ is the biggest architectural addition since OneLake, and it is missing from almost every Fabric architecture article still circulating. Microsoft describes it as a workload for unifying business semantics across data, models and systems, and it contains ontology, planning, Fabric Graph, data agents, operations agents and semantic models.
The placement is what matters architecturally. Before Fabric IQ, business meaning lived inside whichever artifact needed it. A revenue definition sat in a Power BI measure, again in a warehouse view, again in a notebook, and a fourth time in whatever the finance team kept in a spreadsheet. The same fragmentation shows up one level down in how each team builds its star schema in Power BI . Fabric IQ moves that meaning into a governed layer above OneLake that reports, agents and applications all read from.
That matters most when AI enters the picture. A data agent answering a question in natural language has to know what a customer is, what an order is, and which of the four revenue columns is the one people mean. Without an ontology it guesses from column names. With one it resolves against definitions a human approved. Fabric data agents are generally available, support ontology and graph as grounding sources, and can be published into Microsoft 365 Copilot, Copilot Studio, Microsoft Foundry and Teams. We have written separately on the broader set of agentic AI applications on Microsoft Fabric .
One correction worth making, because it appears in a lot of secondary coverage including our own earlier version of this article: Fabric data agents do not read unstructured data . Microsoft states plainly that PDFs, Word documents and text files are outside their scope. If your architecture depends on agents answering from documents, that capability has to come from somewhere else.
Case Study
70% Less Investigation Time with One Governed Ontology on Fabric
A global pharmaceutical enterprise had KPI definitions scattered across individual Power BI dashboards, so the same metric returned different numbers depending on who ran the report. Kanerika built a governed ontology on Microsoft Fabric that standardized 85 or more KPIs and modeled 40 or more entities against the same data in OneLake, cutting investigation and reconciliation time by 70 percent.
Read the Case Study → The pattern behind that engagement is worth naming, because it generalises. The client did not start by building an ontology. They started by listing the metrics that produced arguments in meetings, and modeled only those. An ontology scoped to contested definitions is finishable in a quarter. An ontology scoped to the whole business is a program nobody completes.
Datasheet
Microsoft Fabric Ontology for Governed Analytics and AI
The specifications behind a Fabric IQ ontology build: which entities and relationships to model first, how KPI definitions are governed, and how agents ground against them.
View the Datasheet → Fabric Capacity, F SKUs and What Actually Drives the Bill Capacity is the piece of Fabric architecture that behaves least like the platforms it replaces, and the piece most often sized from a demo. You buy an F SKU in Azure, from F2 up to F8192, billed per second with a one-minute minimum and no commitment required. That SKU number is the count of capacity units available to every workload assigned to it.
F64 is the threshold worth memorising. At F64 and above, users with the free Fabric licence can view Power BI content in a Viewer role. Below F64, every viewer needs a Pro or Premium Per User licence, which frequently costs more than the capacity upgrade would have. Microsoft is also retiring the Power BI Premium per-capacity P SKUs and directing both new and existing customers to F SKUs, so any architecture still drawn around a P1 needs a refresh. Our breakdown of Microsoft Fabric pricing works through what each tier actually costs.
Bursting, Smoothing and the Three Throttle Stages Fabric does not simply stop when you exceed your capacity. It bursts and smooths , and understanding that behaviour is the difference between a capacity plan and a guess.
Bursting lets a single operation temporarily consume more compute than the SKU nominally provides, so a heavy job finishes rather than crawling.Smoothing spreads that consumption across time. Interactive operations smooth over 5 to 64 minutes; background operations smooth over 24 hours. This is why a capacity can look calm during a spike and then throttle the next morning.Overage protection gives you roughly ten minutes of borrowed future capacity before any throttling starts.Throttling arrives in three stages. Past ten minutes of accumulated overage, interactive requests get a 20-second delay. Past 60 minutes, interactive requests are rejected. Past 24 hours, background jobs are rejected too.Sizing in plain numbers works better than a spreadsheet model on the first pass. Take the heaviest recurring job you run today, measure what it consumes on a trial capacity, and multiply by the number of such jobs that could overlap in the same hour. Add the reporting load, which is interactive and smooths over minutes rather than hours. Then check whether your viewer population pushes you to F64 anyway. Most first architectures land between F16 and F64, and most of them are sized by the viewer question rather than the compute one.
F capacities can be paused and resumed, which also clears accumulated throttling. Non-production capacities that sit idle overnight and at weekends are an obvious candidate, and pausing them is one of the few Fabric cost levers that requires no architectural change at all. For a deeper treatment of the cost model, our guide to Microsoft Fabric capacity works through the metrics app in detail.
What Actually Makes a Fabric Workload Slow Capacity is usually blamed for slowness that is really a data-layout problem, and three causes account for most of it.
V-Order not applied. Fabric applies a write-time optimization to Parquet files that makes them faster to read across every Fabric engine. It is on by default in most paths, and a pipeline that writes Delta tables from outside Fabric will not get it. See Microsoft’s guidance on Delta optimization and V-Order .Small files. Streaming or frequent micro-batch writes leave thousands of tiny Parquet files, and every query pays to open them. Run OPTIMIZE to compact them, and treat it as a scheduled job rather than a one-off cleanup.Direct Lake falling back. A Direct Lake semantic model reads Delta tables straight from OneLake, and when it exceeds the guardrails for its capacity it silently reverts to DirectQuery. The report still works, it just gets slower. Monitor for it rather than waiting for someone to complain.Microsoft Fabric Reference Architecture Patterns Most enterprise Fabric builds are a variation on five patterns. Picking one deliberately at the start is worth more than any individual tool choice, because the pattern determines who owns what and where the bottleneck will eventually appear.
Pattern 1: Lakehouse-First Everything lands in a lakehouse, moves through bronze, silver and gold layers, and is served to Power BI through Direct Lake semantic models. Spark does the transformation work.
Use it when you have engineers who write code, varied and semi-structured sources, and data science on the roadmap. It costs you a dependency on Spark skills, and a SQL-oriented reporting team will find the lakehouse endpoint read-only and restrictive.
Pattern 2: Warehouse-First The Fabric Data Warehouse is the centre of gravity. Ingestion lands in staging tables, stored procedures do the work, and the whole thing looks familiar to a team migrating off SQL Server, SSIS or Synapse dedicated pools.
Use it when the existing estate is T-SQL and the team’s skills are the constraint you are designing around, which is the usual shape of a warehouse to lake migration . It costs you some flexibility with unstructured data, and you should know before you start that Fabric Warehouse does not support materialized views , a gap teams routinely discover mid-migration.
Case Study
40% Lower Costs: SSIS to Microsoft Fabric Migration
A large enterprise automated the migration of its SSIS data pipelines into Microsoft Fabric rather than rebuilding them by hand. The warehouse-first result: 30 percent faster data processing, 40 percent lower operational costs, and 25 percent less manual maintenance effort.
Read the Case Study → Pattern 3: Real-Time-First Events flow through Eventstream into an Eventhouse, KQL querysets and real-time dashboards sit on top, and Activator watches for conditions and fires actions. Batch analytics becomes the secondary path rather than the primary one.
Use it when staleness has a measurable cost, such as manufacturing telemetry, fraud signals or logistics exceptions. Microsoft has been shipping heavily here, and our summary of the latest Real-Time Intelligence changes tracks what landed. It costs you a different query language for part of the team, and retention economics that need watching as event volume grows.
Pattern 4: Mirror and Federate Systems of record stay exactly where they are. Fabric mirrors or shortcuts to them, and the analytical estate is assembled in OneLake without a migration project. This is the fastest pattern to stand up and the one that most often gets an initiative funded.
Use it when the sources are stable, owned by other teams, and politically expensive to move. It costs you the transformation layer: mirrored data arrives in source shape, so conformance work still has to happen somewhere downstream.
Pattern 5: Domain-Aligned Data Mesh Each business domain owns its workspaces and publishes data products; a platform team owns capacity, governance and the shared semantic layer. Microsoft explicitly describes Fabric as implementing a data mesh architecture, and domains are a first-class concept in the product.
Use it when you have several genuinely independent business units with their own analysts. It costs you real federated governance effort, and it fails quietly when domains are drawn around org charts rather than around data.
Listen on Spotify
Why Fabric Is Becoming the Go-To Data Platform | SSIS to Fabric Migration
Workspaces, Domains and Region Design Microsoft’s own architecture planning guidance for Fabric is five decisions: compute, regions, workspaces, Fabric IQ and disaster recovery. Two of those five are structural, and both are painful to revisit once data has landed.
Workspaces Are the Unit of Almost Everything A workspace is simultaneously the unit of access control, the unit of capacity assignment, the unit of deployment, and a folder in OneLake. That overloading is why workspace design shows up in every Fabric post-mortem. A single workspace holding development, test and production items cannot be promoted through a deployment pipeline cleanly, and it cannot give a contributor write access to one item without giving it to all of them.
The layout that holds up is one workspace per domain per environment, with a separate shared workspace for genuinely cross-domain assets such as conformed dimensions and the semantic layer. Bind them to Git, and use deployment pipelines rather than manual promotion.
Regions Are the Decision You Cannot Undo Cheaply Your Fabric tenant has a home region, and capacities can live in others. Data residency, latency to source systems and which features have reached your region all follow from that choice. Moving a workspace to another region requires a migration. For a multinational with residency obligations, this decision belongs in the first design session and needs legal in the room, not the platform team alone.
Domains Make the Catalog Usable Domains group workspaces by business area and give each one delegated administration. They also drive how the OneLake catalog presents data to someone browsing for a dataset. Without domains, a tenant with forty workspaces becomes a flat list nobody searches successfully, and the data mesh pattern degrades into a shared drive with better branding.
Checklist
Microsoft Fabric Readiness Checklist
Work through the capacity, workspace, region, governance and migration decisions before the first pipeline ships, in the order that keeps them reversible.
Get the Checklist → Security and Governance in Fabric Architecture Fabric separates permissions into two planes, and most access problems come from conflating them. The control plane governs what you can do to an item: open it, edit it, share it, delete it. The data plane governs what data you can actually see inside it, and in OneLake that plane is called OneLake security.
Identity and Access Azure Active Directory integration provides centralized authentication with single sign-on and multi-factor authentication support. Role-based access control operates at workspace, item, and data levels.
Microsoft renamed Azure Active Directory to Microsoft Entra ID in 2023, so the current documentation and the Fabric admin portal both use the Entra name for the same identity service. Four workspace roles sit on top of it: Admin, Member, Contributor and Viewer. Only Admins and Members can edit OneLake security roles, and those roles exist mainly so that a Viewer can be granted data at a finer grain than the whole item.
OneLake security roles scope down to folders, tables, schemas, rows and columns, which means row-level and column-level security now live with the data rather than being reimplemented in each semantic model. There is also a preview capability that enforces those same roles in authorised third-party engines, so an external tool reading OneLake honours the policy instead of bypassing it.
Governance Through Microsoft Purview Governance in Fabric is delivered by Microsoft Purview rather than a separate Fabric-only tool. That covers the Unified Catalog, data lineage , Information Protection sensitivity labels applied to Fabric items, data loss prevention policies that can restrict access to sensitive assets in KQL databases, SQL databases and warehouses, audit, insider risk management, and governance over what Fabric Copilots and agents are allowed to surface.
A workable data governance framework sits on top of these. The OneLake catalog is where most of this becomes visible day to day. It now has three tabs: Explore for finding data, Govern for assessing governance state and acting on recommendations, and Secure for a unified view of workspace roles and OneLake security roles across items. If your governance design still routes people to the Purview hub for Fabric security insights, those moved into the catalog. For a broader comparison of governance tooling, see our breakdown of Purview versus Collibra .
Reliability and Disaster Recovery for Fabric Architectures Disaster recovery is the section most Fabric architecture articles skip entirely, and it is one of the five planning decisions in Microsoft’s own guidance. The SaaS model shifts the boundary of who owns what, and the boundary is not where teams assume it is.
Microsoft handles platform-level resiliency and provides cross-region replication for OneLake data when you enable it at the capacity level. What Microsoft does not do is recreate your items. Notebooks, pipelines, semantic models, reports and warehouse schemas are your responsibility, which is the strongest practical argument for binding every workspace to Git. Track it under data reliability , alongside the pipelines themselves. A workspace under source control can be rebuilt in another region from the repository. A workspace that was only ever edited in the browser cannot.
Three questions belong in every Fabric design review. How long can each domain tolerate its reporting being unavailable, and does that number justify a second capacity. Which items would have to be rebuilt by hand today, and are they in Git. If the primary region were unavailable for a day, would the source systems still be reachable from the secondary region, or would the same outage simply reappear there.
Microsoft’s Well-Architected guidance for Fabric organises this alongside cost, security, operational excellence and performance efficiency, and running a Fabric design against those five pillars catches more than a component-by-component review does.
Fabric Architecture Mistakes That Cost the Most These are the failures our delivery teams keep being called in to unwind. None of them show up in a proof of concept, which is exactly why they survive into production.
Amit Chandak, Kanerika’s Chief Analytics Officer and a Microsoft MVP, makes the same argument from the delivery side in the session linked at the top of this article. His framing is that Fabric deployments rarely fail on the technology, they fail on decisions made once and never revisited, and the workspace and capacity choices below are the two he sees break most often at enterprise load.
One workspace for everything. It works for three months. Then a contributor needs write access to one pipeline, a semantic model needs promoting without the notebooks beside it, and there is no way to do either. Splitting later means moving items and rewriting every reference to them.Capacity sized from a proof of concept. A trial runs one job at a time. Production runs twelve overlapping, and smoothing means yesterday’s overnight load can throttle this morning’s reports. Size against how many jobs can overlap.Lifting SSIS packages unchanged. Fabric will run the shape of an old package, and you will inherit every workaround built around a constraint that no longer exists. Migration is the cheapest moment to delete logic, and teams routinely skip it. Our walkthrough of the data migration life cycle covers where that pruning belongs.Direct Lake fallback that nobody monitors. Direct Lake silently falls back to DirectQuery when a model exceeds its limits, and the only visible symptom is a report that got slower. Nothing errors, so nothing gets reported.Semantics reimplemented per report. Every report recreating its own revenue measure is the problem Fabric IQ exists to solve. Left alone, it guarantees that any AI agent you add later will be confidently wrong.Shortcuts used where mirroring belonged. A shortcut to an operational database inherits that database’s availability and its query load. If the source cannot absorb analytical reads, mirror it instead.No Git binding. Everything above becomes materially harder to fix, and disaster recovery stops being a plan and becomes a hope.On-Demand Webinar
Snowflake and Fabric: Interoperability, Data Sharing and Migration
Most enterprises run both. This session covers how the two platforms share data through open table formats, where the boundaries should sit, and when a migration beats coexistence.
Watch On Demand → How Kanerika Designs and Migrates Microsoft Fabric Architectures Kanerika is a Microsoft Solutions Partner, and Fabric architecture is one of the places our delivery teams spend the most time. The sequence below is how we run an engagement, and it is deliberately front-loaded on the decisions that are expensive to reverse.
Assess. We inventory what is actually running, which usually differs from what the architecture diagram claims. That means every pipeline, every semantic model, every report and the dependencies between them, plus the ones nobody owns any more. On an SSIS or Informatica estate this is also where we find the packages that can be deleted rather than migrated, which is usually a meaningful share of the total.
Design. Working from the client’s data strategy , we pick one of the five patterns above and write down why, then settle capacity, region, workspace and domain layout before anyone builds. This stage produces the diagram the steering committee signs, and it is where the reversible decisions get separated from the irreversible ones so the team knows which ones to slow down for. It is the same method our data architecture practice applies outside Fabric.
Build and migrate. For migrations we use FLIP, Kanerika’s migration accelerator, which converts pipelines from SSIS , Informatica, Alteryx and Azure Data Factory into Fabric equivalents rather than rewriting them by hand. The SSIS engagement above ran this way and came out at 40 percent lower operational cost with 25 percent less manual maintenance. Hand-migration on an estate that size is where timelines slip.
Govern. Sensitivity labels, OneLake security roles, Purview policies and the semantic layer go in as the data lands, not as a phase two. The pharmaceutical ontology engagement is the clearest illustration: 85 or more KPI definitions standardized once, against governed OneLake data, so both the reports and the agents reading them resolve to the same numbers.
Enable. Our data engineering team hands over with the operating model written down: who owns capacity, who approves a new workspace, who arbitrates a KPI definition. Kanerika also builds directly on the platform rather than only advising on it. At FabCon 2026 we launched two native Fabric workloads , which run inside a customer tenant as first-class Fabric items rather than as an external tool reading Fabric data. Karl, our data insights agent, sits on the same governed semantic layer this article argues for, answering questions against the ontology instead of guessing from column names.
Kanerika Service
Microsoft Fabric Consulting and Migration
Kanerika designs Fabric architectures and migrates SSIS, Informatica, Alteryx, Azure and SQL Server estates onto them, with FLIP handling the pipeline conversion that otherwise consumes the timeline.
Explore Microsoft Fabric Implementation Services → Wrapping Up Microsoft Fabric architecture is easier to reason about than the stack it replaces, because there is one lake underneath and everything else is a choice about what runs on top of it. The choices that matter are also the ones that are hardest to unwind later. Pick a region and a workspace layout before the first pipeline ships. Size capacity against how many jobs overlap. Decide early how much business meaning goes into Fabric IQ, because every agent you add afterwards depends on that answer.
If you are drawing your first Fabric diagram, or redrawing one that no longer matches what Microsoft ships, our team reviews architectures like this every week and will walk yours with you.
Talk to Kanerika
Planning or Redrawing a Microsoft Fabric Architecture?
Kanerika designs Fabric architectures and migrates existing estates onto them. Bring your current diagram and we will tell you which decisions are still reversible.
Schedule a Demo → Frequently Asked Questions
What is the architecture of Microsoft Fabric? Microsoft Fabric architecture is one SaaS platform built on a shared storage layer called OneLake. Nine workloads sit on top of it, covering ingestion, engineering, warehousing, real-time analytics, data science, databases, semantics and reporting. A platform layer underneath supplies governance, security and Copilot. Every workload reads and writes the same data, so no copy step is needed between them.
What are the components of Microsoft Fabric architecture? Microsoft currently ships nine Fabric workloads. They are Power BI, Databases, Data Factory, Data Engineering, Data Warehouse, Real-Time Intelligence, Data Science, Industry Solutions and Fabric IQ. Under all of them sits the platform layer, which holds OneLake storage, Copilot and governance through Microsoft Purview and the OneLake catalog. Older articles list six workloads, which is now out of date.
Is Microsoft Fabric free? Fabric is not free for production use. Compute is bought as an F SKU capacity, starting at F2 and billed per second with a one-minute minimum. Microsoft offers a free trial capacity for evaluation. A free Fabric licence lets a user view Power BI content only when the capacity is F64 or larger.
Is Azure SQL part of Microsoft Fabric? Fabric has its own SQL database, which reached general availability in November 2025 and sits inside the Databases workload. It is built on the Azure SQL Database engine and writes its data into OneLake automatically as Delta tables. A separate Azure SQL Database outside Fabric can also be brought in continuously through mirroring.
Is Microsoft Fabric similar to Databricks? They overlap on Spark and on open table formats, and they differ in shape. Databricks is a data and AI platform assembled from components you configure. Fabric is a SaaS suite with those pieces preassembled and Power BI built in. Fabric can mirror an Azure Databricks Unity Catalog through metadata mirroring, so many enterprises run both together.
What does Microsoft Fabric compete with? Fabric competes with Databricks, Snowflake, Google BigQuery and Amazon Redshift on analytics workloads. It also competes with the assembled Azure stack that many organisations built themselves from Synapse Analytics, Data Factory and Data Lake Storage. In practice most enterprises run Fabric alongside at least one of these and connect them through open table formats.
Is Fabric a PaaS or SaaS? Fabric is software as a service. You buy capacity and the platform handles provisioning, patching, scaling and upgrades. There are no clusters to size and no storage accounts to network. That removes a large amount of infrastructure work and, in exchange, removes some of the low-level control that a platform-as-a-service offering would give you.
What is Microsoft Fabric used for? Enterprises use Fabric to consolidate an analytics estate that grew across several tools. Common uses include building a lakehouse or a warehouse and migrating off SSIS, Synapse or Informatica. Teams also run real-time analytics on event data and serve Power BI with Direct Lake models. Fabric IQ then grounds AI agents on governed business definitions.
Is Fabric a replacement for Synapse? Fabric is the successor to Azure Synapse Analytics for new analytics work, and Microsoft has retired the Synapse naming from the Fabric workloads. Existing Synapse deployments continue to run, and Microsoft publishes migration guidance for dedicated SQL pools and Spark pools. Most enterprises migrate in phases rather than moving the whole estate at once.
What is the difference between Microsoft Fabric and Azure? Azure is the cloud platform. Fabric is one product bought and billed inside Azure that packages the analytics services into a single SaaS experience. Before Fabric, the same outcome required wiring together Data Lake Storage, Data Factory, Synapse Analytics and Power BI. Fabric delivers those capabilities preassembled on one shared storage layer.
Is Microsoft Fabric any good? Fabric works well when an organisation is already invested in Power BI and wants one governed platform instead of several. The consolidation is real and the Direct Lake and mirroring capabilities remove genuine work. It suits teams that value integration over fine-grained control. Teams that tune Spark infrastructure themselves will find the SaaS model restrictive.
What is the equivalent of Microsoft Fabric? The closest equivalents are Databricks with Unity Catalog, Snowflake with its surrounding ecosystem, and Google BigQuery paired with Looker. None of them bundles the same breadth in one SaaS purchase, particularly the built-in Power BI layer. The nearest comparison for an enterprise already on Azure is the older do-it-yourself stack of Synapse, Data Factory and Power BI.
What does the Microsoft Fabric architecture diagram show? A useful Fabric diagram has six horizontal layers and two vertical bands. The layers run from sources, through ingestion, storage, compute and semantics, to consumption. The bands are governance and capacity, and they cross every layer rather than sitting inside one. Drawing governance and capacity as boxes in a row is the most common mistake in Fabric diagrams.
What is Fabric IQ? Fabric IQ is a Fabric workload, currently in preview, for unifying business semantics across data, models and systems. It contains ontology, planning, Fabric Graph, data agents, operations agents and semantic models. Architecturally it sits above OneLake and below everything that consumes data, so reports and AI agents resolve the same definitions.
Is Microsoft Fabric an AI tool? Fabric is a data platform with AI built into it. Copilot assists authoring inside the workloads. Fabric data agents answer questions in natural language against governed data. Fabric IQ supplies the business meaning those agents ground on. Data Science covers model training and deployment. The AI capability sits on the data rather than replacing it.
What is the Microsoft Fabric reference architecture? Microsoft publishes an end-to-end reference architecture in the Azure Architecture Center, staged as ingest, store, process and serve. Store options are the lakehouse, the warehouse, an eventhouse and a SQL database in Fabric. Most enterprise builds then follow one of five patterns, which are lakehouse-first, warehouse-first, real-time-first, mirror-and-federate, and domain-aligned mesh.
How does Microsoft Fabric handle data governance? Governance runs through Microsoft Purview rather than a Fabric-only tool. That covers the Unified Catalog, sensitivity labels, data loss prevention policies, audit and insider risk management. Inside Fabric, the OneLake catalog now has Explore, Govern and Secure tabs. The Secure tab gives one view of workspace roles and OneLake security roles across items.
What is OneLake in Microsoft Fabric? OneLake is the single logical data lake provisioned automatically for every Fabric tenant. Workspaces are containers inside it and items such as lakehouses and warehouses are folders. Tables are stored in Delta Parquet or Apache Iceberg. Shortcuts let OneLake reference data in Amazon S3, Azure Data Lake Storage or Google Cloud Storage without copying it.
What is the difference between a Fabric lakehouse and a Fabric warehouse? A lakehouse is Spark-first. You transform data in notebooks and read it through a SQL analytics endpoint that is read-only. A warehouse is T-SQL-first, supports writes through SQL and handles multi-table transactions. Both store Delta tables in OneLake, so the choice is about which team works in them rather than where the data lives.
How do I size a Microsoft Fabric capacity? Start from concurrency rather than from a single job. Measure your heaviest recurring workload on a trial capacity, then multiply by how many similar jobs could overlap within an hour. Add the interactive reporting load. Then check whether your viewer population forces F64 or larger, since below F64 every viewer needs a Power BI Pro licence.
Can Microsoft Fabric mirror an on-premises SQL Server? Yes, with conditions. SQL Server 2016 through 2022 mirror into OneLake using change data capture, and that covers on-premises instances, Azure virtual machines and other clouds. SQL Server 2025 uses a newer change feed and requires the instance to be connected through Azure Arc. SQL Server 2025 on an Azure virtual machine or on Linux is not supported.
What are the layers of Microsoft Fabric architecture? Sources hold the systems you already run. Ingestion covers pipelines, mirroring, shortcuts and eventstreams. Storage is OneLake. Compute is Spark, the T-SQL warehouse engine, KQL and Direct Lake. Semantics is Fabric IQ and its ontology and models. Consumption is Power BI, data agents and Activator. Governance and capacity apply across all six.
Is Microsoft Fabric the same as Snowflake? No. Snowflake is a cloud data platform centred on a SQL engine with separated storage and compute. Fabric is a broader SaaS suite that bundles ingestion, engineering, warehousing, streaming, data science and Power BI on one lake. The two now interoperate through Apache Iceberg, so many enterprises read the same tables from both rather than choosing one.
Is Fabric an ETL tool? Fabric includes ETL capability but is much larger than an ETL tool. Data Factory inside Fabric provides pipelines, Dataflows Gen2 and more than 200 connectors for extraction and transformation. Fabric also covers storage, warehousing, streaming, machine learning, semantics and reporting. Teams often adopt Fabric for the ETL first and then expand into the rest of the platform.
What are the limitations of Microsoft Fabric? Fabric trades control for convenience. You cannot pin a Spark version indefinitely or place compute outside the capacity. The Fabric Data Warehouse does not support materialized views. Data agents cannot read unstructured files such as PDFs. Region choice is hard to reverse once data lands. Capacity is shared, so one heavy job can slow reporting for everyone.
Does Microsoft Fabric use Azure Data Factory? Fabric has its own Data Factory that shares concepts with Azure Data Factory without being the same service. The Fabric version runs on Fabric capacity, bills against capacity units and adds Dataflows Gen2. An existing Azure Data Factory estate does not appear automatically in Fabric, so moving pipelines across is a migration rather than a setting.
What language is used in Microsoft Fabric? Fabric uses several languages depending on the workload. Data Engineering and Data Science run PySpark, Scala, Spark SQL and R in notebooks. The Data Warehouse uses T-SQL. Real-Time Intelligence uses KQL, with some T-SQL support. Power BI uses DAX and Power Query M. Fabric Graph uses GQL, the ISO standard graph query language.
Will Fabric replace Azure? No. Fabric runs on Azure and is bought through Azure as an F SKU. What Fabric consolidates is the analytics tooling that teams used to assemble from separate Azure services. Synapse Analytics, Data Lake Storage and Data Factory are the usual examples. Azure itself continues to host compute, networking, identity and every other service outside the analytics estate.
