Forum Discussion
Super UserDirect Lake Mode
I am looking to connect my semantic models with direct lake but the ask is, i have to connect without building direct lake semantic model at fabric lake house.
Please let me know is that possible to connect lakehouse views and tables in direct lake mode without creating online semantic models ?
Hi Murtaza_Ghafoor,
Miguel is correct that Direct Lake still requires a semantic model in Fabric.
One current nuance is that you do not necessarily have to create the semantic model manually from the Lakehouse first.
Microsoft now allows you to open Power BI Desktop, use the OneLake catalog, select a Lakehouse or Warehouse, choose the tables, and create the Direct Lake semantic model from there.
However, the semantic model is still created in a Fabric workspace and Power BI Desktop live-edits that remote model. So this does not give you a fully local Direct Lake semantic model.
Microsoft documents this here in the Direct Lake editing in Power BI Desktop guidance.
There is also an important distinction around views.
If you use Direct Lake on OneLake, the Direct Lake tables need to be backed by Delta tables. A normal non-materialized SQL view cannot be used as a true Direct Lake on OneLake table.
With Direct Lake on SQL, Microsoft does allow SQL views to be selected, but queries against those view-based model tables fall back to DirectQuery rather than remaining in Direct Lake.
Microsoft explains that behavior in the Direct Lake overview.
So in practical terms:
- Lakehouse Delta tables -> can use Direct Lake
- normal SQL views -> Direct Lake on SQL can reference them, but they fall back to DirectQuery
- materialized lake views -> persist as Delta data and can behave more like normal Lakehouse tables for Direct Lake scenarios
If your goal is to keep the model definition locally for source control, PBIP/TMDL can help with that, but the Direct Lake semantic model still needs a remote Fabric workspace runtime.So I would not try to avoid the semantic model item itself. I would instead decide whether your source objects should be Delta tables/materialized lake views for true Direct Lake, or SQL views where DirectQuery fallback is acceptable.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
2 Replies
- MFelix
Hi Murtaza_Ghafoor,
The Direct Lake semantic models are always stored on the service, because they need access to the files that are stored in the onelake, so you will need to save them in a fabric capacity workspace. This type of semantic model does not contain any physical data, they are dependent on the live data that is in the Delta Table in the one lake, and the semantic model only stores the metadata.
You can however edit them using the desktop version like you normally do however you won't be able to have access to the reporting pane just access to the tables and model view.
If you want to have a model created and stored on your machine you have to go for the import, or Direct Query using the SQL connection.
Regards
Miguel Félix
- ShivekMaharaj
Community Champion
Hi Murtaza_Ghafoor,
Miguel is correct that Direct Lake still requires a semantic model in Fabric.
One current nuance is that you do not necessarily have to create the semantic model manually from the Lakehouse first.
Microsoft now allows you to open Power BI Desktop, use the OneLake catalog, select a Lakehouse or Warehouse, choose the tables, and create the Direct Lake semantic model from there.
However, the semantic model is still created in a Fabric workspace and Power BI Desktop live-edits that remote model. So this does not give you a fully local Direct Lake semantic model.
Microsoft documents this here in the Direct Lake editing in Power BI Desktop guidance.
There is also an important distinction around views.
If you use Direct Lake on OneLake, the Direct Lake tables need to be backed by Delta tables. A normal non-materialized SQL view cannot be used as a true Direct Lake on OneLake table.
With Direct Lake on SQL, Microsoft does allow SQL views to be selected, but queries against those view-based model tables fall back to DirectQuery rather than remaining in Direct Lake.
Microsoft explains that behavior in the Direct Lake overview.
So in practical terms:
- Lakehouse Delta tables -> can use Direct Lake
- normal SQL views -> Direct Lake on SQL can reference them, but they fall back to DirectQuery
- materialized lake views -> persist as Delta data and can behave more like normal Lakehouse tables for Direct Lake scenarios
If your goal is to keep the model definition locally for source control, PBIP/TMDL can help with that, but the Direct Lake semantic model still needs a remote Fabric workspace runtime.So I would not try to avoid the semantic model item itself. I would instead decide whether your source objects should be Delta tables/materialized lake views for true Direct Lake, or SQL views where DirectQuery fallback is acceptable.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
