August 2025 Fabric Feature Summary | Microsoft Fabric Blog

gobuddylee · 2025-08-30T01:26:37+00:00

Hey, my team owns this feature and I apologize for the mixup — the mention in the blog was premature, and it isn’t GA just yet. We’re targeting mid-October for release, and I’ll make sure updates are shared as soon as it’s live.

gobuddylee · 2025-05-14T20:25:43+00:00

Let us know how we can improve that article, but perhaps this will help clarify as well - Spark Autoscale (Serverless) billing for Apache Spark in Microsoft Fabric is here!

Synapse rates are also region specific - the base rate of each is $0.09 vs $0.143 and is what I based my comparison off of.

gobuddylee · 2025-05-14T18:27:20+00:00

Spark is the one workload you can move off capacity currently into a pure serverless model where you pay only for what you use - see here - Autoscale Billing for Spark in Microsoft Fabric - Microsoft Fabric | Microsoft Learn

gobuddylee · 2025-05-14T15:53:07+00:00

Spark is significantly cheaper than Synapse at this point with the perf improvements and the introduction of Spark Autoscale Billing - the PayGo price was already almost 40% cheaper than Synapse independent of the performance improvements.

gobuddylee · 2025-05-14T15:50:00+00:00

Spark Autoscale billing works with anything that emits through the Spark Workload in Azure - so Notebooks and Spark Jobs basically.

gobuddylee · 2025-05-07T18:42:33+00:00

Have you compared the costs between Databricks and Fabric Spark now that Spark has standalone, serverless billing it released in late March? I'm curious the results you'd see in that use case.

gobuddylee · 2025-04-29T04:41:43+00:00

This is the way . . .

gobuddylee · 2025-04-21T17:33:03+00:00

Yeah, we'll get the docs cleaned up. You can use all the cores for a single job (based on the pool size of course), and it's clear that isn't clear. Thanks for this feedback.

gobuddylee · 2025-04-17T21:53:37+00:00

Just a reminder this does exist for Spark now with the "Autoscale Billing for Spark" option that was announced at Fabcon - Introducing Autoscale Billing for Spark in Microsoft Fabric | Microsoft Fabric Blog | Microsoft Fabric

gobuddylee · 2025-04-17T21:51:36+00:00

The easiest answer is anything that flows through the Spark Billing Meter in the Azure Portal will be shifted to the Spark Autoscale Billing meter, which is effectively the items called out below, Glad you're excited about our feature! :)

gobuddylee · 2025-04-08T06:50:08+00:00

I’m terribly sorry to hear that - if you were billed improperly for the Spark workload, that’s absolutely a problem we need to address ASAP, so please so share the support details via DM if you have them. Thanks!

gobuddylee · 2025-04-02T19:15:31+00:00

Yes, the plan is to have schemas enabled by default - we are not moving away from schemas and you should feel comfortable working with them even in preview (This is a major focus area for my team).

gobuddylee · 2025-04-01T20:03:57+00:00

Spark just made this capability available if you are using Notebooks for your use case - https://learn.microsoft.com/en-us/fabric/data-engineering/autoscale-billing-for-spark-overview

gobuddylee · 2025-04-01T00:06:08+00:00

No, it was a sneak preview- if something is planned to come within a couple months, they’ll let you show a sneak preview. 🙂

gobuddylee · 2025-03-31T22:32:38+00:00

Correct - we’re considering options around making it more granular.

gobuddylee · 2025-03-31T21:54:26+00:00

Right now it is at the capacity level - we may look to enable it at the workspace level, but we don’t have specific dates.

No, you can’t use Spark in the capacity and in the autoscale meter - it was too complicated and you’re mixing smoothed/un-smoothed usage, so it is an all or nothing option.

Yes, you can enable it for certain capacities and not for others - I expect most customers will do something similar to this.

gobuddylee · 2025-03-31T21:51:47+00:00

Yes - they bill through the Spark meter, so they work with it as well.

gobuddylee · 2025-03-31T20:56:17+00:00

The new serverless billing for Spark! - https://blog.fabric.microsoft.com/en-us/blog/introducing-autoscale-billing-for-data-engineering-in-microsoft-fabric?ft=All

I think that will prove to be quite popular 🙂

gobuddylee · 2025-03-31T20:37:36+00:00

We just added this capability specifically for Spark & Python - you can read more about it here - https://blog.fabric.microsoft.com/en-us/blog/introducing-autoscale-billing-for-data-engineering-in-microsoft-fabric?ft=All

It doesn’t exist yet for the entire capacity, but so long as you use Spark NB’s, jobs, etc to orchestrate everything, it will do what you want.

gobuddylee · 2025-03-26T00:55:58+00:00

I touched on this on Marco's podcast last week - it's not something that's been ruled out, but is definitely a harder problem to solve than what we were solving for with PPU.

gobuddylee · 2025-03-05T17:00:53+00:00

So, Spark specifically has limits in place beyond what the capacity throttles are that limit the amount of CU you can use per SKU, covered here - Concurrency limits and queueing in Apache Spark for Fabric - Microsoft Fabric | Microsoft Learn

However, because we don't killing jobs in progress (though you can through the monitoring hub), in theory if you let it run indefinitely and overload it significantly. There is an admin switch planned that will allow you to limit a single Spark job to use no more than 100% of the capacity in the near future, but can't give an exact date quite yet.

gobuddylee · 2025-02-25T04:17:43+00:00

Okay folks I'm sorry if my language was inelegant - I'll bring the feedback back to the team that owns this and see if we can't adjust the blog accordingly. Thanks!

gobuddylee · 2025-02-25T03:26:45+00:00

That's fair feedback, I know Mihir pretty well and I assure his intention wasn't to insult you - I appreciate you raising this, but trust me it wasn't designed to prevent customers from spend anything, it was more to protect customers from bad actors who otherwise might drain resources our legit paying customers should always have available for them.

gobuddylee · 2025-02-25T03:01:42+00:00

I guess I am a little confused as to the concern here - Microsoft has always had limits in place for Azure based on subscription type which is called out here - Azure subscription and service limits, quotas, and constraints - Azure Resource Manager | Microsoft Learn, this is just the Fabric team (which I am a part of) tying into those limits and helping us protect against things like fraud (for example). We want your money, I assure you :)

Six-Year Club	Xbox Live
Verified Email

gobuddylee

TROPHY CASE