The product is considerably better than it was at launch. Warehouses are more mature. SQL Database in Fabric is usable for real transactional workloads. OneLake is more coherent. Capacity tooling has improved. Disaster-recovery features exist that did not exist in the early days. Microsoft has spent three years turning Fabric from an ambitious collection of services into something that increasingly resembles a serious data platform.
And yet some customers still look at it, run a proof of concept, and decide not to move.
I do not think the reason is simply that Fabric is “bad.”
The more interesting problem is trust.
Can a customer predict what a workload will consume before putting it into production? Can they understand when a capacity will throttle? Can they scale without discovering a billing surprise? Can they explain the disaster-recovery plan to an auditor without a whiteboard full of manual recovery steps? Can a team already happy with Azure SQL Database and Power BI tell whether moving deeper into Fabric reduces complexity or merely relocates it?
Those questions matter more than another feature announcement.
Microsoft Fabric is becoming technically capable enough that the conversation is shifting from “Can it do this?” to “Can I operate this confidently for five years?”
That is a harder test.
Access without medium partner: Microsoft Fabric Is Better Than Ever
The first Fabric problem is not price. It is predictability.
Fabric sells compute through Capacity Units, or CUs.
An F32 provides 32 CUs. An F64 provides 64. F128 provides 128, and so on. In theory, that sounds simpler than managing separate clusters, databases, Spark pools, BI capacities, and analytics engines.
In practice, the same shared capacity can be consumed by very different kinds of work: Power BI queries, semantic-model refreshes, data pipelines, warehouses, Spark notebooks, SQL databases, GraphQL, Copilot, and other Fabric services.
That is the attraction. One pool of compute can serve an entire analytics estate.
It is also the source of the anxiety.
A customer rarely asks, “How many Capacity Units does my company need?” They ask something concrete: What will restoring this database cost? What happens if five pipelines run while morning Power BI traffic peaks? How much capacity does this notebook need with 20 concurrent users? If we add another business unit, do we need an F64 or an F128?
Fabric cannot answer many of those questions with a simple pre-purchase number because CU consumption depends on what the operation actually does, how efficiently it runs, how long it runs, and what else is sharing the capacity.
Microsoft’s own capacity-planning guidance effectively acknowledges this. It says sizing can be difficult because compute varies by operation, implementation efficiency, and concurrency. Microsoft recommends using trial or pay-as-you-go capacity, running the real workload, and then studying the Fabric Capacity Metrics app before committing to a reservation.
That is sensible advice.
It is also evidence of the problem.
The easiest way to learn what Fabric will cost is often to run Fabric first.
A CU is simple until you try to explain one to finance
Microsoft has done a lot of work to make CU usage visible after the fact.
The Capacity Metrics app can show utilization, throttling, workload type, item-level consumption, operation-level consumption, carryforward, and recent usage patterns. Microsoft increasingly exposes detailed CU-second information across Fabric workloads.
That is genuinely useful.
But observability is not the same as predictability.
A cloud architect can explain a VM reasonably easily: eight cores, 32GB RAM, this hourly price. A database tier may have limits and caveats, but buyers can usually reason about the unit they are purchasing.
A Fabric capacity behaves more like a shared budget with several invisible clocks running at once.
Interactive work is smoothed. Background work can be smoothed over 24 hours. Fabric allows bursting above the nominal capacity for short periods. Then overages can become carryforward consumption that future capacity has to burn down.
Throttling does not necessarily begin the moment the chart crosses 100%. Fabric provides overage protection first. After enough future capacity has been consumed, interactive requests can be delayed, then rejected, and severe sustained overuse can eventually cause background operations to be rejected too.
This engineering is clever.
It makes short spikes less painful and lets customers size closer to average demand instead of peak demand.
It also means the mental model is harder than “we bought 32 units and used 33.”
The bill may be simple at the reservation level.
The operating behavior is not.
Fabric can be fast precisely because it lets you borrow from the future
This part deserves a fair explanation because Fabric’s capacity model is often criticized as if every spike immediately means throttling.
That is not how it works.
Microsoft uses bursting and smoothing so large operations can consume more compute when they need it. Interactive jobs are generally smoothed over minutes. Many background jobs are spread over a 24-hour window for capacity accounting.
That can make Fabric feel wonderfully fast.
A warehouse query can burst. A refresh can finish quickly. A background job does not necessarily need to be artificially scheduled at 2 a.m. just to avoid a short capacity spike.
The catch is that the capacity has to pay for that burst later.
If the system keeps accumulating more work than the purchased SKU can repay, Fabric starts protecting itself. The customer then sees delays, rejections, or long burndown periods.
The architecture makes sense.
The user experience can still feel unpredictable when several teams share the same capacity.
A platform team can understand the math.
A business user just sees the report suddenly telling them to try again later.
The Power BI migration makes the trust problem more sensitive
There is also a reason some customers feel as if Fabric arrived before they asked for it.
Microsoft is retiring Power BI Premium per-capacity P SKUs. New P SKUs are no longer sold, and existing subscriptions end at the end of their current agreement terms. Microsoft’s migration guidance directs those customers toward Fabric F SKUs.
For Microsoft, that is a product consolidation.
For a customer that only wanted Power BI Premium, it can feel different.
They may not have made an architectural decision to adopt a unified data platform. They made a licensing decision years ago to buy Power BI capacity, and the platform underneath that decision is now changing.
That does not mean the customer is forced to use every Fabric workload.
It does mean Fabric capacity becomes part of the commercial conversation whether or not the organization was looking for a new data architecture.
That changes the emotional context of every technical limitation.
A missing feature in a product you voluntarily chose is annoying.
A missing feature in the platform you were migrated toward feels like something else.
One criticism from July is already outdated: Fabric capacity can be resized
This is where criticism needs to be careful.
A widely circulated argument this summer claimed that if a customer reserved an F32 and later discovered they needed F64, they would effectively be stuck and forced to buy an entirely new capacity.
That is no longer an accurate description of Microsoft’s documented options.
A Fabric capacity itself can be resized in Azure. Microsoft documents scaling an F SKU up or down through the Azure portal. Scaling smaller capacities upward is generally quick, although licensing changes can take longer to propagate in some cases.
Reservations are more nuanced, but they are not frozen forever either.
Microsoft’s June 2026 reservation documentation explicitly includes “Increase the size of a Fabric Capacity reservation.” The documented options are to use the reservation exchange process or buy additional Fabric reservation units.
That does not make capacity planning trivial.
If you scale above the amount covered by your reservation, the extra compute can be charged at pay-as-you-go rates until you increase the reserved quantity. Scaling below the reserved amount does not magically reduce the reservation bill either.
But the blanket claim that an F32 reservation simply cannot be increased is outdated.
Fabric deserves criticism based on the platform that exists now, not the version people were angry about three months ago.
The stronger criticism is that Microsoft tells you to experiment before you reserve
The more revealing part of Microsoft’s reservation guidance is not whether an F32 can become something larger.
It is the advice to choose the right size first.
That sounds obvious.
Then read the capacity-planning documentation.
Microsoft recommends testing real workloads on trial or pay-as-you-go capacity and using the Capacity Metrics app to determine what size is required.
In other words, reservations can save money, but accurately sizing one often requires workload observation first.
For sophisticated cloud teams, this is normal.
For a customer coming from a relatively understandable Power BI Premium capacity or a predictable Azure SQL bill, it can feel like another layer of operational expertise they now need to build.
Fabric is selling simplification at the product level.
It can create complexity at the capacity-management level.
Both things can be true.
SQL Database in Fabric exposes the maturity gap most clearly
This is where I think customer hesitation becomes much easier to defend.
SQL Database in Fabric is an impressive product. It uses the same SQL Database Engine lineage as Azure SQL Database, integrates tightly with OneLake, automatically exposes analytical data into the Fabric ecosystem, supports automatic backups, and uses availability zones where supported.
For operational applications that need to live close to Fabric analytics, the architecture is compelling.
But as of September 2026, Microsoft’s own feature-comparison documentation still lists several business-continuity capabilities available in Azure SQL Database as not currently supported in SQL Database in Fabric.
That list includes active geo-replication, failover groups, geo-restore, and long-term retention.
Automatic backups exist. Point-in-time restore exists. Availability-zone protection exists.
Those are important protections.
They are not the same thing as the mature cross-region controls Azure SQL Database customers may already rely on.
This is the kind of gap that can end a migration conversation immediately for a business-critical database.
Not because Fabric SQL is unusable.
Because the existing platform already does something the replacement cannot yet do.
Fabric’s disaster-recovery story is better than “there is no DR”
Another common criticism goes too far in the opposite direction.
Fabric does have disaster-recovery capabilities.
OneLake supports geo-replication when disaster recovery is enabled for a capacity in supported paired regions. Microsoft duplicates data into another geographic region. OneLake also provides local redundancy or zone redundancy depending on configuration and region, and deleted OneLake files have soft-delete protection.
That is real DR infrastructure.
Microsoft’s latest reliability guidance also describes regional failover behavior and says failover typically completes in less than an hour, although actual recovery depends on workload and region.
So “Fabric has no disaster recovery” is not accurate.
The more important criticism is what happens after the data survives.
Recovering the data is not the same as recovering the platform
Microsoft’s own current reliability documentation is unusually honest here.
After a severe regional disaster, the customer recovery plan can require creating a new Fabric capacity in another region, recreating workspaces, recreating items with the same names, and then restoring the relevant items and solution functionality.
Microsoft’s Well-Architected guidance says many Fabric items rely on continuous data replication rather than traditional backups. It recommends manual backups for critical assets outside OneLake and tells customers to rehearse failover and restoration.
That is the distinction enterprise architects care about.
Data durability asks whether the bytes survived.
Service recovery asks whether the business can actually run again.
OneLake geo-replication helps with the first problem.
The second can still contain significant customer-owned work.
For an analytics environment, that may be acceptable.
For a business-critical operational platform with an aggressive recovery-time objective, the difference is enormous.
This is why Azure SQL can still be the rational answer
Suppose an organization already runs several hundred gigabytes in Azure SQL Database.
The system is understood. The team has monitoring. The backup model is known. Active geo-replication or failover groups can be designed into the application. Operations staff understand the failure modes.
Now the database is growing and performance is becoming difficult.
Fabric looks attractive because the company already uses Power BI and wants closer integration with analytics.
But moving the database into Fabric SQL does not only ask, “Will queries run faster?”
It asks the team to change its capacity model, disaster-recovery model, operational tooling, billing model, and possibly its assumptions about cross-region availability.
That is a much larger migration than the product diagram makes it look.
Sometimes the correct answer will be Fabric.
Sometimes the correct answer will be Azure SQL Hyperscale, a different Azure SQL tier, a warehouse pattern, or keeping the operational system where it is while mirroring data into Fabric.
Fabric’s biggest competitor inside Microsoft may be Microsoft’s own mature services.
The all-in-one platform creates a noisy-neighbor problem customers can actually feel
Fabric’s greatest selling point is consolidation.
Power BI, SQL, warehousing, Spark, pipelines, real-time analytics, notebooks, AI features and OneLake can all share the same platform.
That can reduce duplicated copies and simplify architecture.
It also means one capacity can become a shared economic boundary for workloads owned by completely different teams.
A poorly optimized notebook can consume capacity. A large semantic-model refresh can consume capacity. A warehouse workload can consume capacity. A pipeline can consume capacity. An operational database can consume capacity.
Microsoft provides governance controls and monitoring, but the platform team still has to decide which workloads should share a capacity and which should be isolated.
This is where “one platform” can quietly turn into several capacities, several governance domains, several chargeback rules, and a permanent FinOps job.
The architecture becomes simpler on the diagram.
The organization around it may not.
Autoscale helps, but it changes the financial question rather than removing it
Microsoft has also been adding more ways to absorb unexpected demand, including autoscale and overage capabilities in parts of the capacity model.
That improves resilience.
It also creates a second anxiety: if the system avoids throttling by consuming additional paid capacity, how much protection should the customer enable?
Microsoft’s current overage guidance is blunt about the trade-off. Capacity overage can prevent throttling, but overage usage can be billed at a premium compared with ordinary pay-as-you-go capacity. Microsoft recommends limits and monitoring rather than treating overage as a permanent sizing strategy.
So the customer gets another choice.
Throttle. Scale. Autoscale. Allow overage. Split workloads. Optimize queries. Buy a larger reservation.
The platform gives administrators several tools.
The fact that the administrator needs all of them explains why some customers do not experience Fabric as the simplification the marketing promises.
Microsoft Fabric is not failing. It is crossing into the part where trust matters more than features.
Early platform adoption is driven by capability.
Does it have a warehouse? Does it have Spark? Does it integrate with Power BI? Can it use OneLake? Can I build pipelines? Can I run SQL?
Fabric can answer “yes” to an increasingly long list.
Mature platform adoption is driven by different questions.
What happens at 9:15 on Monday morning when every workload runs? What will next month’s bill look like? What is our RPO? What is our RTO? Can we fail into another region? Which part does Microsoft recover? Which part does my team rebuild? Can I resize without losing my discount? Can I prove all of this to an auditor?
Those questions are less exciting than product demos.
They decide whether the platform gets the company’s most important data.
Why customers say no even when Fabric passes the technical test
I think this is the part Microsoft should pay the most attention to.
A platform can be technically capable and still lose the deal.
Customers are not buying a feature list. They are buying predictability.
They want to know what the architecture costs. They want to know what happens when it breaks. They want to know which workloads can hurt other workloads. They want to know what is automatic and what is their responsibility. They want to know whether a one-year or three-year commitment will still make sense after the data estate doubles.
Fabric is improving quickly enough that some criticism becomes obsolete within months. The reservation-upgrade complaint is a good example.
But fast improvement creates its own trust problem.
If the answer to an architecture objection is “that limitation changed last month,” the customer may be impressed.
They may also wonder which other assumptions will change next month.
The best Fabric deployment may be the one that does less
There is a temptation with integrated platforms to migrate everything because everything can live there.
I think that is the wrong starting point.
Use Fabric where its architecture gives a clear advantage.
Power BI workloads already moving to F capacity are an obvious candidate. Analytical data that benefits from OneLake and Direct Lake is another. Warehousing, data engineering, real-time analytics and cross-workload collaboration can be compelling.
A business-critical operational database that depends on mature active geo-replication may be a different decision.
A workload whose CU behavior is poorly understood may deserve a pay-as-you-go proof of concept before anyone signs a reservation.
A mission-critical recovery plan should be tested, not inferred from a product diagram.
Fabric becomes less scary when organizations stop treating adoption as an all-or-nothing platform referendum.
The real Fabric problem is not lock-in. It is confidence.
Microsoft wants Fabric to feel like the obvious place for data teams already living inside Power BI and Azure.
Technically, that vision is getting easier to believe.
Commercially and operationally, some customers still hesitate because Fabric asks them to accept a new abstraction at exactly the layer where companies hate surprises: money and resilience.
Capacity Units make heterogeneous compute easier to pool. They also make individual operations harder to predict before observation.
OneLake geo-replication makes the data layer more resilient. It does not automatically recreate every workspace, item and service in another region.
Fabric SQL brings operational databases into the same platform as analytics. It still does not have every cross-region capability of Azure SQL Database.
Reserved capacity can now be increased. You still need to know roughly how much to reserve.
That is the balanced version of the Fabric story in September 2026.
The product is better. Several old complaints are no longer fair. Some of the remaining complaints are more serious because they are exactly the things mature enterprises care about most.
Microsoft does not need another launch event to fix that.
It needs Fabric to become boring.
Boring bills. Boring scaling. Boring failover. Boring recovery.
Boring enough that an architect can put the company’s most important data on the platform and stop thinking about the platform itself.
Fabric is much closer to that point than it was three years ago.
The customers still saying no are telling Microsoft what remains.
Sources
Microsoft Learn — Power BI Premium to Microsoft Fabric migration overview
https://learn.microsoft.com/en-us/power-bi/support/premium-migration-overview
Microsoft Learn — Evaluate and optimize your Microsoft Fabric capacity
https://learn.microsoft.com/en-us/fabric/enterprise/optimize-capacity
Microsoft Learn — Capacity Metrics app calculations
https://learn.microsoft.com/en-us/fabric/enterprise/metrics-app-calculations
Microsoft Learn — Understand capacity throttling and smoothing
https://learn.microsoft.com/en-us/fabric/enterprise/throttling
Microsoft Learn — Scale your Fabric capacity
https://learn.microsoft.com/en-us/fabric/enterprise/scale-capacity
Microsoft Learn — Save costs with Microsoft Fabric Capacity reservations
https://learn.microsoft.com/en-us/azure/cost-management-billing/reservations/fabric-capacity
Microsoft Learn — OneLake disaster recovery and data protection
https://learn.microsoft.com/en-us/fabric/onelake/onelake-disaster-recovery
Microsoft Learn — Reliability in Microsoft Fabric
https://learn.microsoft.com/en-us/azure/reliability/reliability-fabric
Microsoft Learn — Reliability considerations for Microsoft Fabric workloads
https://learn.microsoft.com/en-us/azure/well-architected/microsoft-fabric/reliability
Microsoft Learn — SQL database in Fabric limitations
https://learn.microsoft.com/en-us/fabric/database/sql/limitations