Forum Discussion
Advocate IVDoes Fabric Runtime 2.0 update affect Querying LH via Fabric Browser UI functions?
From what you describe, browser UI queries shouldn't be affected by the runtime change.
Queries through the SQL analytics endpoint (SQL query editor, Explore, Power BI on top) run on the SQL engine, not Spark, so the runtime version doesn't come into it.
The SparkCore usage on your Lakehouse items most likely comes from Spark background operations like:
- Someone previewing a table in the Lakehouse explorer
- Load to Tables from the explorer
- Table maintenance (OPTIMIZE / VACUUM) run from the UI or a pipeline
- Materialized lake views or shortcut transformations, if you use them
None of those need a notebook.
Runtime 2.0 matters for your own Spark items: notebooks, Spark job definitions, environments and libraries. Test those before switching an existing workspace. Also, the new Delta 4.x features are experimental, so don't enable them on tables the SQL endpoint or Power BI read.
Hope that clears it up.
Memorable MemberHi anon97242,
Good question to ask before the migration. I can't confirm the exact internals from Microsoft documentation, so treat the first part as my understanding and the second part as a way to verify it in your own tenant.
Why SparkCore shows up for a Lakehouse: the SQL analytics endpoint (T-SQL) runs on the warehouse engine and is billed as SQL, not Spark. But several things you can do from the Lakehouse in the browser are Spark-backed even if you never open a notebook: Load to tables, table maintenance (OPTIMIZE / VACUUM), and some table or file previews. If your users are running Spark SQL or doing those actions through the Lakehouse UI, that would explain SparkCore usage on LH items.
Do you need to test for 2.0? Runtime applies as a workspace-level Spark setting, so the question to answer is which runtime those workspaces are on and whether the UI actions you rely on behave the same on 2.0. Check the current setting through the API:
GET https://api.fabric.microsoft.com/v1/workspaces/{workspaceId}/spark/settings
-> look at "environment.runtimeVersion"Then, to find out what is actually generating the SparkCore usage:
1. Capacity Metrics app -> Item history -> filter SparkCore -> note the operation names and user
2. Monitor hub -> filter by item type / user -> match start times to the usage spikes
3. Ask one user to repeat the suspected action (preview, load to table, maintenance) and watch which operation appearsFinally, I'd run the same actions in a non-production workspace with Runtime 2.0 selected, since a runtime change affects the whole workspace, and compare results and CU usage with prod. If you don't use notebooks, that smaller test list is probably all you need.
So my overall approach would be:
Identify which UI actions generate SparkCore (Capacity Metrics + Monitor hub)
Check workspace runtime via Spark settings API
Repeat those actions in a test workspace on Runtime 2.0
Compare behaviour + CU, then roll out per workspaceAI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
Advocate IVThanks jubinsoni Those are the steps we used to identify that we were indeed using Spark when we perform actions in the Browser UI.
My question though is this: Does Microsoft manage this piece on our behalf (similar to WH Delta files) or do we manage it?
To put it even more simply, if we take no action, do not update Runtime, will the Fabric Browser UI continue to function past March 31 2027 end of support date?