Fabric Runtime 2.0 reached general availability on August 17, 2026. As I write this, Microsoft’s own runtime documentation still says all new workspaces currently use Runtime 1.3. The plan is to make Fabric Runtime 2.0 the default runtime selection in the user experience and the default runtime for new workspaces and environment items in late September 2026. That is two weeks away. Maybe less.

I want to flag two documented breakages before that switch flips. These are not hypothetical risks. Microsoft has warned about both in the documentation. Both are fixable, but one of them (the Delta Lake side) has a non-reversibility clause that matters a lot if you miss it.

What Is Changing and When

Microsoft’s stated plan: Fabric Runtime 2.0 becomes the default for new workspaces and new environment items in late September 2026. No specific day is given. “The plan is to” is Microsoft’s language, and I am using it deliberately. Plans slip. As I write this, the runtime documentation still reads “by default, all new workspaces currently use Runtime 1.3.” That sentence will vanish when the switch flips.

What does not change automatically: existing workspaces. Existing jobs. Existing environment items. Only new workspaces and new environment items default to 2.0 once the plan executes. Existing infrastructure stays on whatever runtime you configured. But the pressure to migrate accumulates. Runtime 1.3 enters Long Term Support on October 1, 2026, with support running through March 2027. That is a six-month runway. Comfortable, but not infinite.

The practical answer: opt in to Fabric Runtime 2.0 deliberately, on a scoped workspace first, and shake out the breakages before the automatic default does it for you.

The Version Jump at a Glance

This is a major version bump on nearly every component. Readers familiar with the Spark 3.4 upgrade cycle at Databricks already know that minor Spark version changes can ripple through library compatibility and shuffle behavior. Spark 3.5 to 4.1 is not a minor change.

Every major component jumps at least one version. The Delta protocol default change from reader 1/writer 2 to reader 3/writer 7 is what breaks cross-workload reads.

The headline components:

• Apache Spark: 3.5 → 4.1
• Delta Lake: 3.2 → 4.2
• Python: 3.11 → 3.13
• Java: 11 → 21
• Scala: 2.12 → 2.13
• Delta default protocol: reader 1 / writer 2 (Runtime 1.3) → reader 3 / writer 7 with Deletion Vectors (Runtime 2.0)

Two things worth calling out explicitly. R users: SparkR is deprecated in Spark 4.x and may be removed in a future version. If you have SparkR notebooks, that clock is running. And on performance, according to Microsoft’s benchmarks, Fabric Runtime 2.0 delivers up to six times faster performance compared to open-source Spark on TPC-DS workloads. I flag it because it is a real engineering motivation for migrating. I also flag that it is a vendor benchmark, not an independent measurement. Fabric Runtime 2.0 end of support is August 31, 2028. So the upgrade runway is meaningful.

Breakage 1: Python 3.13 and Your Environment Libraries

Python 3.11 to Python 3.13 is a two-minor-version jump. That is the jump Runtime 1.3 to Fabric Runtime 2.0 makes. When the Python version changes between runtimes, the library management system migrates your libraries from the old runtime to the new one, but those libraries may not work properly after the switch. You are responsible for updating or replacing any that break.

Microsoft is explicit about this. The responsibility sits with you, not with the platform. The migration is automatic; the validation is not.

Two practical notes that are scoping, not new claims. Per-notebook %pip install calls and the notebook Resources folder are session-scoped. They execute at session startup, not at environment publish time, so they are not subject to this breakage in the same way. The risk is concentrated in environment items that carry pinned wheel files or custom packages. Those are the ones to audit first.

What to do: before the switch flips, open each environment item you own, test it against Fabric Runtime 2.0 explicitly (more on that mechanism in the migration path section below), and verify that every library your jobs depend on resolves cleanly. If a library does not, update it or find a replacement. There is no shortcut here.

Breakage 2: Delta Lake 4.2 Experimental Features Break Cross-Workload Reads

This one is more subtle, and the non-reversibility is what makes it dangerous.

Delta Lake 4.2 ships several new experimental features. Microsoft is direct: these features are experimental and only work on Spark experiences: notebooks and Spark Job Definitions. If a table needs to be read by any other Fabric workload, you should not enable those features on that table. Full stop.

The specific failure that is best documented is V2 Checkpoints. Only Spark notebooks and Spark jobs can read and write tables with V2 Checkpoint files. Lakehouse and SQL analytics endpoints do not correctly list tables containing V2 Checkpoint files. That phrasing, “do not correctly list”, is Microsoft’s language, and it matters. This is not a hard error that surfaces cleanly in logs. The table listing behavior is wrong. Power BI Direct Lake and the SQL analytics endpoint are reader-only experiences; they cannot set table features, which means they also cannot clear the feature once it is set.

The protocol version gap makes this worse. Fabric Runtime 2.0 defaults to reader version 3, writer version 7 with Deletion Vectors. Runtime 1.3 defaults to reader version 1, writer version 2. Any tool that reads Delta tables and does not support reader version 3 cannot read tables that have been written with Fabric Runtime 2.0 defaults. Python notebooks in Fabric are a case in point: they use delta-rs, DuckDB, and Polars rather than the Spark Delta Lake reader and writer, and delta-rs as currently pinned in Fabric does not support deletion vectors, column mapping, liquid clustering writes, or type widening.

For background on how Delta Lake operates inside Fabric, see Delta Lake in Microsoft Fabric and Delta UniForm interoperability across engines.

The irreversibility clause is the one I want you to sit with. Delta Lake protocol upgrades via upgradeTableProtocol are non-reversible. Microsoft’s documentation is explicit: once you execute the upgrade, you cannot undo it without recreating the table. If you enable a Delta 4.2 experimental feature on a table that is also read by your SQL analytics endpoint or Power BI Direct Lake semantic model, you have permanently broken those readers’ access to that table. The fix is to recreate the table, not to roll back a setting.

Only Spark experiences on Runtime 2.0 can use the new Delta 4.2 features. Enabling them on a table any other workload reads permanently breaks those readers.

The Safe Migration Path: Opt In Before the Switch Flips

The right order is: opt in voluntarily on a scoped workspace, validate, then let the default switch happen with nothing to surprise you.

Workspace-level opt-in. Go to Workspace Settings > Data Engineering/Science > Spark Settings > Environment tab. Under the Runtime version dropdown, select “2.0 (Spark 4.1, Delta 4.2)” and save. This changes the default for all new notebooks and Spark jobs in that workspace.

Environment-item-level opt-in. Open or create an Environment item. Under the Runtime dropdown, select “2.0 (Spark 4.1, Delta 4.2)”, save, and publish. This is the more surgical option. You scope Fabric Runtime 2.0 to specific notebooks or Spark Job Definitions without touching the workspace default.

Testing with early access. Fabric runtime release channels are a preview feature that lets you test upcoming runtime changes before they become the default. Set spark.computeConf.runtime.releaseChannel=earlyAccess in your Spark configuration. The full property is spark.fabric.pools.skipStarterPools=true, and early access runs only on custom pools, which start sessions more slowly than the Starter Pool. Two things the docs bury. The channel setting is immutable for the life of a Spark session, so switching channels means starting a new one. And when the validation window ends, the early access channel is promoted automatically to become the new default. Microsoft does not publish how long that window is.

So early access is not a place to park a workload. It is a place to run a test and read the result. For teams managing production lakehouses it is still the right instrument for validation, with the caveat that the whole mechanism is preview.

Good Delta table maintenance habits apply here too. See Advanced Optimization and Maintenance for Delta Tables in Fabric for a detailed rundown of compaction, Z-ordering, and protocol management.

What to Do With Your Delta Tables Before Upgrading

Three rules, all derivable from the ledger above.

Rule 1: Audit before you enable. Before you enable any Delta Lake 4.2 experimental features on a table, know which workloads read that table. If the SQL analytics endpoint, Power BI Direct Lake, or a Python notebook reads it, do not enable those features. The feature list is not short: V2 Checkpoints are the best-documented failure, but the general warning covers all Delta 4.2-specific experimental features.

Rule 2: Treat feature enablement as permanent. Protocol upgrades via upgradeTableProtocol are irreversible. Once a feature raises the reader or writer version, it cannot be undone without recreating the table. Build your governance process around that constraint. If you are uncertain whether a downstream workload supports a given feature, assume it does not.

Rule 3: Know your reader landscape. The SQL analytics endpoint and Power BI Direct Lake are reader-only. They cannot set or clear table features. Python notebooks (delta-rs) do not support deletion vectors, column mapping, liquid clustering writes, or type widening. Any table that these workloads need to read should be treated as a read-constrained table, meaning its Delta features need to stay within what those readers can handle.

For the specifics of managed versus external Delta tables and how feature enablement interacts with table ownership, see Managed and External Tables in Fabric Lakehouse.

Runtime 1.3 Is Not Going Away Immediately

The default switch is not end-of-life for Runtime 1.3, but the label has already changed. The runtime comparison table now lists Runtime 1.3’s release stage as EOSA against Runtime 2.0’s GA, and the Runtime 1.3 page spells that out: “Fabric Runtime 1.3 is in the end of support announced (EOSA) stage.” End of support announced, not reached. Runtime 1.3 enters Long Term Support on October 1, 2026, with support extending through March 2027.

I will be honest about one thing here, because it tripped me up. Microsoft’s lifecycle page describes LTS as a stage that follows GA, and separately puts Runtime 1.3 into LTS after an announced end-of-support date.

Read the table alone and you conclude support ends on September 30, 2026. Read the footnote attached to that same row and you get six more months. The footnote is the one that matters, and March 2027 is the date to plan against. But if a colleague tells you support ends in September, they are reading the same page you are. That is six months from the planned default flip. Teams that are not ready to migrate on day one have a genuine runway.

The practical move: pin existing workspaces to Runtime 1.3 explicitly, run your Fabric Runtime 2.0 validation on a scoped environment, and migrate on your own schedule before March 2027. Do not rely on LTS to mean “nothing changes”. It means “supported, but no new features and minimal backports.” The migration work still needs to happen. March 2027 is the hard stop.

One thing to note for teams migrating to Fabric Runtime 2.0: liquid clustering writes are not supported in Python notebooks on 2.0 (a delta-rs limitation). For broader context on what liquid clustering means operationally, Liquid Clustering 101 covers the fundamentals. If your workload depends on liquid clustering writes, you need to be on Spark notebooks, not Python notebooks, under Fabric Runtime 2.0.

The default switch matters most for teams creating new workspaces and environment items. If your current workspaces are stable and pinned, the September flip is noise. If you have been letting new workspaces default without setting a runtime explicitly. That is when the plan, once it executes, changes your behavior automatically.

Two weeks to test. The time to do it is now, not after the switch.

Conclusion

Two weeks of testing, and the decision splits three ways.

If your workspaces are already pinned to a runtime explicitly, the late-September default flip is noise. Nothing changes under you. Spend the time on the Delta side instead, because that risk does not arrive on a schedule. It arrives the first time somebody enables an experimental feature on a shared table.

If you let new workspaces take the default, you have until late September before new environment items start landing on Spark 4.1, Delta Lake 4.2 and Python 3.13. Pin them now. Pinning takes a minute; discovering the change through a failed job takes an afternoon and happens at the worst time.

And if you are building on Delta Lake 4.2 features, treat every enablement as a one-way door. Protocol upgrades cannot be reversed. The SQL analytics endpoint and Power BI Direct Lake are reader-only and cannot negotiate their way past a table they do not understand. One upgradeTableProtocol on a table that Power BI reads, and you are rebuilding the table, not rolling back a setting.

The runway is real: Runtime 1.3 enters Long Term Support on October 1, 2026 and is supported through March 2027. Six months is enough time to migrate properly. It is also enough time to forget, and March 2027 is a hard stop.

Do the audit this week. Pin the workspaces you care about, list the tables your non-Spark workloads read, and put Runtime 2.0 on a scoped environment where a failure costs you nothing.