Fabric Capacities and Workspaces: F SKUs, Trials, and Setting Up Your First Workspace*
⚡ Practitioner24 min readSep 22, 2026Updated Sep 22, 2026
You've heard the pitch for Microsoft Fabric. Maybe you've even read the overview of what Fabric actually is and how it fits with Power BI. Now comes the moment where the rubber meets the road: you need to actually run something. And before you can run anything in Fabric — before you can create a lakehouse, load data, write a Spark notebook, or publish a report — you need two things in place: a capacity and a workspace.
This is where a lot of practitioners get stuck. The licensing model for Fabric is meaningfully different from the per-user Power BI Premium model most data teams are familiar with. You're not buying seats; you're buying compute. Understanding the difference between an F2 and an F64, knowing when a trial capacity is good enough, and understanding what a workspace actually is in the Fabric model — these aren't administrative trivialities. They directly affect what you can build, how fast it runs, and what your team can access.
By the end of this lesson, you'll be able to make informed decisions about which Fabric capacity tier fits your situation, activate and manage a Fabric trial, create and configure a workspace the right way, assign that workspace to a capacity, and understand the permission model well enough to avoid the classic mistakes that lock teammates out or give too much access to the wrong people.
What you'll learn:
This lesson assumes you're comfortable navigating the Microsoft Fabric portal and have a basic understanding of what Fabric workloads exist. You should have an Entra ID (formerly Azure AD) account with either a Power BI Pro, Power BI Premium Per User (PPU), or Microsoft 365 license. If you want to follow along with the hands-on exercise, you'll need either an existing Fabric capacity assigned to your tenant or the ability to start a Fabric trial (more on that shortly).
Before we talk SKUs and pricing, you need a mental model for what a Fabric capacity is. In traditional Power BI Premium, capacity was about isolating your Power BI workloads on dedicated hardware so they didn't compete with the shared infrastructure. Fabric extends that idea dramatically.
A Fabric capacity is a pool of Capacity Units (CUs) — Microsoft's abstraction layer over the underlying compute resources. CUs power every workload in Fabric: Spark jobs in a notebook, SQL queries against a warehouse, dataflow refreshes, pipeline runs, Power BI report rendering, real-time intelligence processing — all of it draws from the same CU pool. This unified resource model is one of Fabric's most important design decisions, because it means you're not paying separately for a Spark cluster, a SQL pool, and a Power BI Premium node. You buy a block of CUs, and Fabric distributes them across whatever you're doing.
Key insight
CUs are shared across workloads, but they're also shared across time. Fabric uses a concept called smoothing where bursts of high consumption are spread across a 24-hour rolling window. A short, intense Spark job that would have blown past your capacity limit in a legacy system gets smoothed out so it doesn't immediately throttle everything else. This is a significant practical advantage for teams with spiky workloads.
The CU pool is region-specific. When you provision a Fabric capacity, you pick an Azure region, and all the compute for that capacity lives there. Data processed by workloads on that capacity doesn't automatically cross regions — relevant for compliance and data residency requirements.
Microsoft sells Fabric capacity under the F SKU naming scheme. Here's the practical breakdown of the tiers you'll encounter most often:
| SKU | Capacity Units | Typical Use Case |
|---|---|---|
| F2 | 2 CUs | Individual experimentation, proof of concept |
| F4 | 4 CUs | Small team development, light workloads |
| F8 | 8 CUs | Small production workloads, departmental analytics |
| F16 | 16 CUs | Medium production, multiple concurrent workloads |
| F32 | 32 CUs | Serious production environments |
| F64 | 64 CUs | Enterprise workloads, replaces P1 Premium |
| F128 | 128 CUs | Large enterprise |
| F256 | 256 CUs | Very large scale |
| F512 | 512 CUs | Massive scale |
| F1024 | 1024 CUs | Fabric's largest publicly available tier |
| F2048 | 2048 CUs | Hyperscale, typically requires Microsoft engagement |
A few things to understand about this table:
F64 is the meaningful threshold for most enterprise teams. Below F64, some Power BI features that were part of Power BI Premium P1 aren't available — specifically things like paginated reports at scale, XMLA read/write endpoints for third-party tools, and certain deployment pipeline features. If your team is migrating from P1 and expects full feature parity, F64 is your minimum.
F2 is surprisingly capable for development. For a solo practitioner learning Fabric, or for a small team building and testing pipelines before moving to production, F2 is functional. You'll hit throttling if you try to run heavy Spark jobs concurrently with dataflow refreshes, but for sequential development work it's fine.
The cost model is pay-as-you-go or reserved. You can run an F SKU in pay-as-you-go mode through Azure, meaning you can pause it when you're not using it and only pay for active hours. You can also purchase one-month or one-year reserved capacity for significant discounts. This is a major advantage over traditional Power BI Premium, where you paid 24/7 whether you were using it or not.
Tip
If you're building a development and testing environment, spin up an F4 or F8 on pay-as-you-go, pause it at the end of each workday, and you'll pay a fraction of what reserved capacity costs. Many teams run a small dev capacity on pay-as-you-go and a larger production capacity on reserved pricing.
You may encounter Power BI Premium P SKUs and Azure Embedded A SKUs in your organization. Here's how they map:
P SKUs (P1, P2, P3, P4, P5) are the original Power BI Premium capacity SKUs purchased through Microsoft 365 licensing. They support Fabric workloads starting from P1, but P SKUs are being gradually deprecated in favor of F SKUs. If your organization has existing P SKU capacity, Fabric workloads will run on it — but new purchases should use F SKUs.
A SKUs (A1 through A8) are Azure Embedded SKUs originally intended for independent software vendors embedding Power BI. They map to the same underlying CU values as F SKUs but have some licensing constraints that make them less suitable for internal enterprise use.
For practical purposes: if you're setting up new Fabric infrastructure today, use F SKUs. If you have existing P SKU capacity, Fabric will work on it, but plan to migrate when those licenses come up for renewal.
Note
The approximate CU equivalence between old and new: P1 ≈ F64, P2 ≈ F128, P3 ≈ F256, P4 ≈ F512. If you had P1 and you're evaluating Fabric migration, F64 is your starting benchmark.
If your organization doesn't have a Fabric capacity yet, Microsoft offers a 60-day Fabric trial capacity. Here's what you actually get and what the constraints are.
The Fabric trial provisions a capacity equivalent to F64 — 64 CUs — attached to your individual user account. This is not a tenant-wide capacity by default. You can create workspaces assigned to your trial capacity and share them with colleagues, but the capacity is tied to you as the person who activated it.
The trial gives you access to all Fabric workloads: lakehouses, warehouses, data pipelines, Dataflow Gen2, Spark notebooks, real-time intelligence, and Power BI premium features. For learning and proof-of-concept work, it's genuinely useful.
The trial capacity isn't suitable for production. It expires after 60 days with no grace period — when it expires, workspaces assigned to it lose their capacity assignment, and any premium-only features stop working. The underlying data in OneLake doesn't disappear (it's tied to workspace storage, not the capacity), but the compute goes away.
Trial capacity also can't be paused or scaled. You get F64 equivalent CUs for 60 days, full stop.
Warning
When your trial expires, workspaces assigned to it will lose their capacity assignment but will not be deleted. Your data is safe in OneLake. However, features that require premium capacity — including most Fabric workloads — will be unavailable until you assign the workspace to a paid capacity. Plan your transition before the 60 days are up.
Once the trial is active, you'll notice a new option appears when you create or assign workspaces: your personal trial capacity appears in the capacity dropdown as Trial (your name).
Tip
If you don't see the "Start trial" option, your Fabric administrator may have disabled trial activations for the tenant. Check with whoever manages your Microsoft 365 or Power BI admin settings. Tenant admins control this via the Fabric Admin portal under Tenant settings > Users can try Microsoft Fabric paid features.
When you're ready to move beyond the trial, you provision Fabric capacity through the Azure portal, not through the Microsoft 365 admin center. This trips up people who are used to managing Power BI Premium through M365 licensing.
rg-fabric-production.fabric-prod-eastus or contoso-fabric-dev.Once provisioned, the capacity appears in the Fabric Admin portal (accessible from the gear icon in the Fabric portal) under Capacities. From there, Fabric administrators can see utilization metrics, configure workload settings, and manage which workspaces are assigned.
These are different roles and the distinction matters:
A workspace admin cannot assign their workspace to a capacity they don't have admin rights on. This is intentional: it prevents teams from self-assigning to production capacity without approval.
In Power BI, a workspace was essentially a container for reports, dashboards, and datasets. In Fabric, a workspace is still a container, but it's much more fundamental — it's the organizational unit for every Fabric item you create.
Every lakehouse, warehouse, data pipeline, notebook, Dataflow Gen2, semantic model, and report lives inside a workspace. Workspaces in Fabric map directly to OneLake's folder structure: each workspace gets its own logical partition in OneLake, and the items inside it are organized beneath it.
Key insight
Workspaces are also the unit of access control. Permissions in Fabric are set at the workspace level first, then can be refined at the item level. This means your workspace design directly determines your security model. Getting workspace structure right before you build anything else saves significant pain later.
There's no single right answer for workspace structure, but here are the patterns that work well in practice:
Pattern 1: Workspaces by environment (dev/test/prod) Create separate workspaces for development, testing, and production. Use Fabric deployment pipelines to promote items between them. This is the cleanest pattern for teams building data products that need to go through a release process.
Example structure:
Contoso Sales - DevContoso Sales - TestContoso Sales - ProdPattern 2: Workspaces by domain Separate workspaces for different business domains or data products. Finance, Operations, Marketing each get their own workspace (or their own dev/test/prod set).
Pattern 3: Workspaces by team Each data team or squad manages their own workspace. Works well in federated data organizations where different teams own different data products.
The pattern you should avoid: putting everything in one workspace. It seems simpler at first, but it collapses access control (everyone can see everything), makes it impossible to promote items through environments cleanly, and creates a messy inventory of items with no organizational logic.
Here's how to create a workspace correctly the first time.
In the Fabric portal (app.fabric.microsoft.com), look at the left navigation panel. You'll see Workspaces with an expand arrow. Click it to see your existing workspaces. At the bottom of that panel (or via the + New workspace button), create a new one.
The workspace name is visible to everyone in your organization who has access to the Fabric portal. Use a naming convention your team agrees on:
[Team/Domain] - [Environment] works well: Finance Analytics - Dev, Supply Chain - Prod.
Add a description. It takes 30 seconds and saves your colleagues from having to ask what a workspace is for.
After entering the name and description, expand the Advanced section. This is where the important configuration lives.
License mode: This determines what capacity the workspace uses. Your options will vary based on what's available in your tenant:
For Fabric workloads, you need Trial, Fabric capacity, or Premium capacity. Choose the appropriate one.
Capacity: If you selected Fabric capacity, choose which specific capacity to assign the workspace to from the dropdown.
Default storage format: This is a subtle but important setting. For a workspace that will contain Fabric items (lakehouses, warehouses, notebooks), leave this as the default. If you're creating a workspace primarily for Power BI reports and semantic models without Fabric compute items, the default still works fine.
Data model settings: For most Fabric workspaces, leave these at defaults unless you have specific requirements around large model storage formats.
Click Create. The workspace is provisioned immediately. You'll land inside the new, empty workspace.
Verify the capacity assignment worked: click the Workspace settings gear icon in the top right of the workspace view and look at the License info section. You should see your capacity name and the SKU tier confirmed there.
Warning
If the workspace shows as Pro or Free in the License info after you created it with a capacity assignment, the assignment didn't stick. This can happen if you don't have the right permissions to assign to that capacity. Go back into workspace settings, and under License, explicitly select your capacity again. If you still can't assign it, contact your Fabric capacity administrator.
Workspace roles in Fabric are inherited from Power BI's model but extend to cover all Fabric items. There are four roles, and understanding where each one's boundary is will save you a lot of frustration.
Admin Full control of the workspace: can add/remove members, change settings, delete the workspace, assign it to a capacity, and create/edit/delete all items. Reserve this for the data platform team leads or workspace owners. Most contributors don't need Admin.
Member Can create, edit, and delete items in the workspace. Can also add contributors and viewers to the workspace (but not other Members or Admins). Members can publish reports and manage dataflows. This is the right role for senior data engineers and analysts who are building things.
Contributor Can create and edit items in the workspace, but cannot manage workspace membership. This is the right role for data engineers and analysts who are building content but shouldn't be managing access.
Viewer Read-only access to items in the workspace. Can view reports, can see that lakehouses and warehouses exist, but cannot read the underlying data directly without being granted item-level permissions separately. Viewers are for consumers of finished data products.
Tip
There's a common misconception that giving someone Viewer access to a workspace means they can query the lakehouse or warehouse. It doesn't. Workspace Viewer only means they can see reports and dashboards built on top of those data stores. To query a lakehouse or warehouse directly (via SQL endpoint or Spark), a user needs at least Contributor access, or you need to grant them item-level SQL permissions explicitly. This distinction matters enormously when building shared data platforms.
Inside your workspace, click Manage access in the top right (it looks like a person icon with a + sign). From here:
Use security groups rather than individual users whenever possible. Assigning roles to individual users creates a maintenance nightmare as people join and leave teams. Add a security group (managed in Entra ID), add users to that group, and your Fabric workspace permissions stay accurate automatically.
Beyond workspace roles, Fabric supports item-level permissions for specific scenarios. The most relevant ones:
Item-level permissions are additive — a user gets the more permissive of their workspace role and any item-level permissions they've been granted. They're useful for cases like exposing a specific curated lakehouse table to a business team without giving that team access to the rest of the workspace.
Once your workspace is assigned to a capacity and your team starts using it, you need to understand how the capacity will respond under load. Fabric doesn't hard-stop when you hit your CU limit the way some systems do — it throttles.
Fabric tracks CU consumption using a smoothing window of 10 minutes for interactive operations (report queries, SQL queries) and 24 hours for background operations (Spark jobs, dataflow refreshes, pipeline runs). If you burn through more CUs than your SKU's allocation during the smoothing window, Fabric applies throttling in stages:
The practical implication: a short, intense Spark job on an F8 won't immediately break your reports. The 24-hour smoothing means the CUs spent on that job are amortized over time. But if you're running continuous heavy workloads on an undersized capacity, you will hit throttling, and it will show up as slow or failing interactive queries.
Microsoft provides the Microsoft Fabric Capacity Metrics app — a Power BI template app you install from AppSource. It connects to your Fabric capacity's telemetry and shows you:
Install this app when you spin up a capacity. You want to be monitoring utilization from the start, not after you've already hit problems.
Tip
When evaluating whether to upgrade your F SKU, look at the Capacity Metrics app's CU % utilization chart over a rolling 7-day period. If you're consistently above 70% utilization with throttling events during business hours, it's time to upgrade. Occasional spikes during off-hours are usually fine — the smoothing window handles them.
Let's walk through the complete setup from scratch. This exercise assumes you have a Microsoft organizational account with at least a Power BI Pro license.
Verify it worked: click the account avatar again and you should see Trial capacity listed under your account, along with days remaining.
[YourName] Fabric Lab - Dev. Be specific — this helps you find it later among other workspaces.You should land inside a fresh, empty workspace. The breadcrumb at the top will show your workspace name.
While you're in Workspace settings, take a few minutes to explore:
Repeat Part 2-3, but name this workspace [YourName] Fabric Lab - Prod. This gives you a dev/prod pair to work with in subsequent exercises throughout the learning path. You won't promote anything between them in this exercise, but the structure is in place.
Cause: The workspace is on Pro or PPU license mode, not Fabric capacity or trial. Fix: Go to Workspace settings > License, and assign the workspace to a Fabric or trial capacity. If you don't see those options, you either don't have a trial active or your org doesn't have Fabric capacity provisioned.
Cause: Your tenant admin has disabled Fabric trials. Fix: Ask your Microsoft 365 or Fabric admin to enable trials under Tenant settings in the Fabric Admin portal. The setting is Users can try Microsoft Fabric paid features.
Cause: Sometimes a page refresh is needed after a capacity assignment change, or there's a brief propagation delay. Fix: Refresh the browser. Wait 2-3 minutes after changing a capacity assignment before testing workload availability.
Cause: They're a Viewer, not a Contributor. Fix: Go to Manage access and change their role to Contributor or Member.
Cause: F8 (8 CUs) is on the lower end for Spark. The Spark starter pool on small capacities is limited. Fix: Check the Capacity Metrics app to confirm you're hitting throttling. If you are, either upgrade the capacity or schedule heavy Spark jobs during off-peak hours so the smoothing window has headroom. As an interim measure, configure the Spark pool to use a smaller node count for development jobs.
Cause: Workspace Admins can delete workspaces, including all items in them. Fix: Deleted workspaces go to a soft-deleted state for 90 days. Navigate to Workspace settings in the Fabric Admin portal (gear icon > Admin portal > Workspaces), filter to show deleted workspaces, and restore it. This requires Fabric tenant administrator access.
Warning
Workspace restoration recovers the workspace and its items, but capacity assignments and some settings may need to be reconfigured after restoration. Always verify all items are intact and working after restoring a deleted workspace.
You now have a solid foundation for understanding how Fabric compute and organization actually work. Let's recap the key points:
Capacities are pools of Capacity Units (CUs) that power all Fabric workloads. F SKUs range from F2 (light development) to F2048 (hyperscale), and F64 is the practical threshold for full enterprise feature parity with Power BI Premium P1. Fabric's smoothing model means short bursts of high CU usage don't immediately cause problems, but sustained overload leads to progressive throttling.
The Fabric trial gives you 60 days of F64-equivalent capacity tied to your user account. It's genuinely useful for learning and proof of concept, but you need to plan your transition to paid capacity before it expires. Your data in OneLake survives the trial expiration; compute access doesn't.
Workspaces are the organizational and security unit of Fabric. Design your workspace structure before you build anything — environment-based patterns (dev/test/prod) work well for most teams. Use security groups for role assignments, not individual users. Understand that Viewer access doesn't mean data access; it means report access.
With your workspace in place, you're ready to start building actual Fabric items. The next lesson in this path covers creating your first lakehouse and loading data into OneLake — which is where Fabric's data architecture really starts to show its value.
For production deployments, install the Microsoft Fabric Capacity Metrics app as soon as you have a real capacity running. You want utilization visibility from day one, not after you've already experienced throttling in front of your stakeholders.