The Executive Insight
By the time Fabric shows up in an executive meeting, two stories are usually competing:
- “Fabric is too expensive.”
- “Fabric is cheaper than what we had before.”
Both can be true.
Fabric is capacity‑based. You’re not buying “a BI tool” or “a warehouse license.” You’re buying a pool of compute units (CUs) and letting every workload—Power BI, lakehouse, warehouse, Spark, Real‑Time Intelligence—drink from the same tap.
That architecture is powerful. Idle capacity from one workload can be used by another. You stop paying for five half‑utilized platforms.
But it also means this:
Fabric is never expensive or cheap in isolation. It is only expensive or cheap relative to your workload discipline.
Issue #13 is about that discipline—not as “cost cutting,” but as a way of thinking about value per CU.
The Pricing Reality: You’re Buying a Shared Engine, Not Seats
Current 2026 pricing guidance shows the pattern clearly:
- Small SKUs: F2–F8
- Mid SKUs: F16–F64
- High SKUs: F128+
You can run pay‑as‑you‑go or reserved (with 20–40% discounts), but the core idea doesn’t change:
- You’re paying for CUs over time, not per report or per user.
- Every query, every refresh, every Spark notebook, every Eventhouse operation draws from the same pool.
That unified engine is what makes Fabric attractive. It’s also what makes unconstrained experimentation dangerous.
The Real Problem: “We Never Changed the SKU After the Pilot”
One of the biggest cost anti‑patterns I see is depressingly simple:
- Someone spins up an F64 for a pilot—“just to make sure performance isn’t the problem.”
- The pilot goes well. More workloads move in.
- No one ever revisits the original sizing. The F64 just becomes “what we run on.”
- Months later, someone in finance looks at the bill and says, “Why are we paying for all of this?”
Field guides and FinOps write‑ups call this out explicitly: assuming the first capacity size is the right one forever is a classic mistake.
Under the hood:
- Fabric lets you scale F SKUs up and down; pay‑as‑you‑go adjusts with size.
- Reserved instances don’t get cheaper if you scale below the reserved level—you’re still on the hook for that commitment.
So “just scale down whenever” isn’t a strategy either. You have to right‑size with both usage and purchasing model in mind.
The Hidden Costs: Smoothing, Bursting, Background, and Multi‑Env
Several “hidden cost” patterns are already well documented by practitioners:
- Smoothing & Bursting
- Background CU Drain
- Multi‑Environment Costs
All of these are symptoms of the same thing:
You’re treating capacity as “infrastructure” you buy once, instead of a shared engine whose behavior you choreograph.
The Strategic Shift: Think “FinOps for Fabric,” Not “Turn Off Things”
FinOps guidance for Fabric is converging on a few themes:
- Quantify Value, Not Just Cost
- Understand CU Consumption
- Optimize Usage
- Manage the Practice
This isn’t about saying “no” to everything. It’s about aligning spend with value on a platform where everything shares the same bill.
Hope for Lean Teams: You Don’t Need a FinOps Department
For lean SMBs, “FinOps” can sound like an enterprise‑only word.
But Fabric’s cost model actually gives small teams a chance to be more disciplined by design:
- Start Small, Intentionally
- Pick One Owner for Cost Signals
- Use Fabric Itself as Your Cost Data Platform
You don’t need a committee. You need a habit:
“We look at CU consumption and cost alongside usage and value, every month.”
Where I Fit In (For Partners and Leaders)
If you’ve been reading along for a few weeks, a through‑line should be clear:
- Fabric is not just a technical platform.
- It’s an economic platform—capacity, workloads, and governance all show up on the same bill.
Most partners can explain how to build in Fabric. Fewer can explain:
- How to right‑size for a $50M–$100M org without overcommitting.
- How to design architectures that respect the shared engine, not treat it like infinite free compute.
- How to connect Cost Management, Capacity Metrics, and usage analytics into a coherent FinOps practice.
That’s the layer I operate in.
I work with:
- Microsoft and analytics partners who want Fabric projects to come with a cost story stakeholders trust.
- CIOs, CDOs, and CTOs who don’t just want “Fabric is powerful,” but “Fabric is powerful and financially sane for us.”
- Operators and finance leaders who need to see CU consumption tied to real products and outcomes—not just line items.
If you’re already sold on Fabric’s technical promise and your next question is “How do we make sure this stays economically healthy?”, that’s where it makes sense to talk.
Isaac Truong | Founder, Allston Yale
Enterprise-grade analytics for $50M–$100M SMBs
Power BI | Fabric | Azure | Data Strategy
? Book a 20-min Fabric diagnostic →
? Subscribe to get Friday Fabric Facts in your inbox (plus early access to templates) ?
LinkedIn: Connect with me for daily Fabric tips
Friday Fabric Facts #13: Originally Posted on LinkedIn, April 24, 2026