Fabric Runtime 2.0: Don't Wait Until It Becomes Your Problem

Never trust a runtime upgrade until you've actually tested it.

Great news... unless one of your favorite packages suddenly decides it doesn't like Python 3.13 anymore.

With Runtime 2.0 becoming the default for new sessions by the end of September 2026, now is the time to start testing. Don't wait until the switch is made for you.

First Runtime 2.0 Experience

When Runtime 2.0 first entered Preview in March 2026, I was eager to try it. Spark 4.0, Delta 4.0... what's not to like? Not long after, Microsoft announced a move to Spark 4.1, Delta 4.2, and Python 3.13. That sounded even better.

Unfortunately, that's where my problems started. At the time, I generate semantic models using the excellent semantic-link-labs package. One of the first tests in my dedicated Fabric environment immediately failed. The problem? Python 3.13.

When I tested it the update of Pyhton 3.13 broke the environment build.

Because I generate my semantic models using the semantic-link-labs package, I ran into build errors. It turned out this package wasn't compatible with Python 3.13.

What's interesting is that the latest release states:

requires-python=">=3.10,<3.14"

On paper, everything should have worked.…but in practice it didn’t.

So I did what every consultant does, stop fighting and switch back. So I stuck with Runtime 1.3 and waited for the bug to be fixed.

The Fabric Community

One thing I always appreciate about the Fabric community is how quickly people jump in to help. In the summer, I posted the bug on the Fabric Community blog, and several community members pointed me toward the root cause and shared their own findings.

Over the summer the compatibility issues were gradually resolved. Since semantic-link-labs 0.15.2, released in July, fixed the problem.

Python 3.13 Support · Issue #1243 · microsoft/semantic-link-labs

With Runtime 2.0 now generally available, it was finally time to give it another shot.

Rebuild Environment

The migration itself turned out to be straightforward. After updating the packages to the right versions, the environment was successfully build.

Compared to 1.3, our environment configuration changed.

Yaml after:

• semantic-link==0.14.2
• semantic-link-labs==0.15.2

Before I was running:

• semantic-link==0.8.4
• semantic-link-labs==0.8.11

As you can see, the package versions have gone up significantly. Other packages stayed the same for Runtime 2.0. With this configuration, building the Spark environment finally succeeded, and I could test my daily load processes and notebooks.

The Performance Test

Naturally, I was hoping for some performance gains. You know the feeling:

"New runtime. New Spark version. Faster, right?"

Well... not exactly.

Initially I thought Runtime 2.0's Native Execution Engine (NEE) might significantly improve performance. Then I remembered something important: I was already using NEE in Runtime 1.3.My bad. 😉

So I did not encounter a magical speed boost. But that makes sense.

Our solution isn't processing enormous datasets, and our load process is largely sequential. We have a main notebook that creates tables one after another rather than aggressively parallelizing workloads.

In other words:

Spark can't optimize architecture decisions that were intentionally designed to be simple. Sometimes the bottleneck isn't the runtime.

So Why Upgrade?

For me, the biggest benefit isn't shaving a few minutes off a load process. It's being ready for what's next. By moving to Runtime 2.0 now, we're aligned with Fabric's future default settings and can start exploring the new capabilities in Spark 4.1 and Delta 4.2 before they become the norm.

Since we use Spark SQL extensively throughout our Fabric solution, the new capabilities in Spark 4.1 create opportunities to write cleaner, more expressive, and potentially better-performing workloads in the future.

That is where I expect the real value of Runtime 2.0 to emerge. Not because it magically makes everything faster. But because it gives developers more tools to build better solutions.