Series: Getting Started & Tenant Foundations
Fabric hands you an entire toolbox of analytics workloads. Using all of them isn’t the goal — using the right ones is.
Resist the shiny-object trap. Fabric packages Power BI, Data Factory, Data Engineering, Data Warehouse, Data Science, and Real-Time Intelligence into one platform, and it’s tempting to adopt all of them at once. Map each workload to a business problem you already have, and bring in only the pieces that solve something real today. Every workload you adopt without a real use case behind it is one more thing your team has to learn, maintain, and eventually explain to an auditor.
Know what each workload is for. Data Factory ingests and transforms data from many sources, Data Engineering uses Spark notebooks for large-scale processing, Data Warehouse gives you a SQL engine with separate compute and storage, Data Science builds models, and Real-Time Intelligence handles streaming data like IoT and clickstreams. Power BI turns it all into reports people use. Most organizations start with Data Factory and Power BI alone and only add the rest once a specific project genuinely calls for it.
Size capacity to the work, not the org chart. Fabric capacity is measured in Capacity Units across SKUs from F2 up to F1024 and beyond, and sizing depends on data volumes, concurrent users, and workloads run, not company size. A small team with modest data may fit a small SKU; heavy reporting plus big Spark jobs needs real headroom. A hundred-person company running heavy Spark transformations can easily need more capacity than a thousand-person company that mostly views dashboards.
Let real usage decide. Rather than guessing, spin up a trial capacity, run your workloads, and watch the Capacity Metrics app to see how many CUs you consume at peak. That data beats any spreadsheet estimate, and it’s the approach Microsoft’s own capacity planning guidance recommends. Pay particular attention to your peak periods, not your averages — a capacity sized for a typical Tuesday will still choke during month-end close if you didn’t measure for it.
Plan in phases, not one big bang. A pragmatic target-state design lays out where you want to land: which workloads, capacities, and governance model. A phased roadmap gets you there through a pilot, an early production release, and broader rollout, validating assumptions before committing a large budget. Each phase should teach you something that changes or confirms your plan for the next one, rather than just being a slower version of doing everything at once.
Leave room to grow. As adoption spreads, scale capacity up, split workloads across multiple capacities so one team’s job doesn’t slow another’s, or move mission-critical work onto its own tier. Building in that flexibility now saves an awkward re-architecture later. A little extra thought about workload isolation today is a lot cheaper than migrating a live production capacity under pressure next year.
You don’t need every workload on day one, and you don’t need the biggest SKU to start. You need a design matching what your teams do with data today, plus a clear path for what’s next.
From the archive, if you want more on this: Microsoft Fabric Project Advice: Getting into the Thick of It · Moving from Power BI to Microsoft Fabric
To learn more: What is Microsoft Fabric · Plan your Fabric capacity size · Plan your Microsoft Fabric capacity: strategic guide overview · Microsoft Fabric capacity planning: plan your first deployment · Microsoft Fabric adoption roadmap (all Microsoft Learn)
This post is part of the Fabric & Power BI Essentials series — see the full series intro and article list there.
← Previous: Assessing Your Organizational Team’s Fabric Maturity | Next →: Understanding Fabric Capacity Units (CUs) and F-SKUs
