Direct Lake Semantic Models in Power BI: How to Build One

Question 1

How to create a direct lake semantic model?

Answer

You use the Fabric portal to create a Direct Lake semantic model in a workspace. It’s a simple process that involves selecting which tables from a single lakehouse or warehouse to add to the semantic model. You can then use the web modeling experience to further develop the semantic model.

Question 2

How to enable direct lake in Power BI?

Answer

Enable preview feature

Live editing semantic models in Direct Lake mode with Power BI Desktop is enabled by default. You can disable this feature by turning off the Live edit of Power BI semantic models in Direct Lake mode preview selection, found in Options and Settings > Options > Preview features.

Question 3

How to create a semantic data model in Power BI?

Answer

Steps to Create a Semantic Model

Import Data. The first step in building a semantic model in Power BI is importing data from various sources. …
Define Relationships. After importing data, the next step is to define relationships between tables.
Create Measures and Calculate Columns.
Build Hierarchies.
Publish Model.

Question 4

What is the difference between semantic model and direct lake?

Answer

Semantic models provide a logical and user-friendly structure for data analysis. Direct Lake mode complements this structure by offering quick and direct access to data. In essence, Direct Lake is a fast track to load source data directly into the Power BI engine, ready for analysis.

Question 5

What is the difference between Delta Lake and Direct Lake?

Answer

The main difference is the storage format. Direct Lake can directly read Delta files from OneLake! The Delta storage format is mainly based on top of Parquet. Parquet is a columnar-based storage format which is quite similar to the proprietary one used by Microsoft for Import Mode.

Question 6

How do you create a data lake in Power BI?

Answer

Connect to Azure Data Lake Storage from Connect Cloud
Log into Connect Cloud, click Connections and click Add Connection.
Select “Azure Data Lake Storage” from the Add Connection panel.
Enter the necessary authentication properties to connect to Azure Data Lake Storage.
Click Create & Test.

Question 7

What is a direct lake semantic model?

Answer

A direct lake semantic model is a Power BI dataset that queries data directly from OneLake storage without importing or caching it first, combining the speed of import mode with the freshness of DirectQuery mode. Traditional import models copy data into Power BI’s in-memory engine, which means refreshes are required to reflect changes. DirectQuery models hit the source on every interaction, which can slow performance. Direct lake mode bypasses both limitations by reading delta-parquet files stored in Microsoft Fabric’s OneLake directly into memory on demand, so users get fast query response times against large, up-to-date datasets. This approach works specifically within the Microsoft Fabric ecosystem and requires your data to be stored as delta tables in a lakehouse or warehouse. When a query runs, the semantic model loads only the relevant data partitions into memory rather than the full dataset, making it efficient even at scale. If the data volume exceeds available memory capacity, the model automatically falls back to DirectQuery to maintain functionality. For organizations working with large volumes of operational or analytical data, direct lake semantic models reduce the infrastructure overhead of scheduled refreshes while keeping reports current, which is a meaningful advantage in time-sensitive reporting scenarios.

Question 8

What is the difference between direct lake on OneLake and direct lake on SQL?

Answer

Direct Lake on OneLake reads data directly from Parquet files stored in OneLake without going through any SQL endpoint, while Direct Lake on SQL routes queries through a SQL analytics endpoint, which adds a translation layer between Power BI and the underlying data. With Direct Lake on OneLake, the semantic model accesses delta tables natively, delivering the fastest query performance since there is no intermediate processing. This mode is ideal when your data is well-organized in a Fabric lakehouse or warehouse and you want maximum throughput for large datasets. Direct Lake on SQL, by contrast, uses the SQL analytics endpoint to serve data, which gives you more flexibility for applying row-level security, views, or other SQL-based transformations before data reaches the semantic model. The tradeoff is slightly higher latency compared to the pure OneLake path. From a practical standpoint, choose Direct Lake on OneLake when raw performance is the priority and your delta tables are already structured for reporting. Choose Direct Lake on SQL when you need to enforce security policies or apply logic at the data layer before exposing it to Power BI. Understanding this distinction helps you design semantic models that balance speed, governance, and flexibility based on your specific reporting requirements.

Question 9

How to select a semantic model in direct lake mode?

Answer

To select a semantic model in Direct Lake mode, open Power BI Desktop or the Fabric portal, create a new semantic model, and choose Direct Lake as the connection type when prompted to select a storage mode. In the Fabric portal, navigate to your workspace, select New and then Semantic model, and point it to a Lakehouse or warehouse delta table as the data source. Direct Lake mode is automatically applied when your semantic model connects directly to OneLake delta tables without importing or caching data through DirectQuery. In Power BI Desktop, you can verify the storage mode by checking the model properties, where each table should reflect Direct Lake as its query mode. To confirm you are working in Direct Lake mode rather than falling back to DirectQuery, ensure your delta tables are properly formatted, row counts stay within capacity limits, and credentials are correctly configured. Fallback to DirectQuery happens automatically when certain conditions are not met, so validating your setup in the Fabric capacity metrics app helps confirm true Direct Lake execution. Kanerika works with organizations to design and validate Direct Lake semantic models in Microsoft Fabric, ensuring optimal configuration so queries consistently hit the high-performance Direct Lake path rather than defaulting to slower fallback modes.

Question 10

How to create a semantic model from a lakehouse?

Answer

To create a semantic model from a lakehouse in Microsoft Fabric, open your lakehouse in the Fabric portal and click New semantic model from the ribbon or the lakehouse editor toolbar. From there, select the tables you want to include in the model, then click Confirm to generate the model automatically. Once the model is created, it opens in the web modeling experience where you can define relationships between tables, create measures using DAX, set up hierarchies, and configure column properties. The model is built on Direct Lake mode by default, meaning it reads data directly from the OneLake Delta tables without requiring an import or scheduled refresh. After setting up your relationships and measures, you can publish or share the semantic model and connect Power BI reports to it just like any other dataset. Because the model stays in sync with the underlying lakehouse data, reports built on top of it always reflect the latest available data without manual refresh steps. For teams working with large enterprise data volumes, this workflow significantly reduces the complexity of the traditional import-and-refresh cycle. Organizations implementing Microsoft Fabric data architectures, including those working with Kanerika on Fabric deployments, typically build their reporting layer directly on lakehouse-backed semantic models to keep analytical pipelines lean and scalable.

Question 11

What are the 4 types of data models?

Answer

The four types of data models are conceptual, logical, physical, and dimensional models. Each serves a distinct purpose in how data is structured, interpreted, and stored across a system. A conceptual data model defines the high-level relationships between business entities without technical detail, making it useful for aligning stakeholders early in a project. A logical data model adds structure by defining attributes, data types, and relationships in a technology-agnostic way. A physical data model translates that logical design into a database-specific schema, including tables, indexes, and constraints optimized for a particular storage engine. A dimensional data model, most relevant to Power BI and Direct Lake semantic models, organizes data into facts and dimensions to support fast analytical queries. This star or snowflake schema structure is what Direct Lake semantic models in Microsoft Fabric are built around, allowing Power BI to query OneLake delta tables directly without importing or caching data. When building Direct Lake semantic models, understanding dimensional modeling is especially important because the performance benefits depend on well-structured fact and dimension tables. Kanerika’s data engineering and Power BI implementation work consistently applies these modeling principles to ensure semantic layers are both performant and analytically sound.

Question 12

Why use Direct Lake?

Answer

Direct Lake mode gives you the speed of in-memory analysis without the cost and complexity of importing data into Power BI datasets. Traditional Import mode requires scheduled refreshes, meaning your reports can show stale data until the next refresh cycle runs. DirectQuery avoids that problem but hits the source database on every interaction, which slows down dashboards significantly at scale. Direct Lake sits between these two approaches by reading data directly from OneLake’s Delta Parquet files in Fabric, so reports reflect near-real-time data while maintaining fast query performance. The practical benefits are meaningful for large-scale analytics. You avoid duplicating data across storage layers, which reduces both storage costs and governance overhead. There are no refresh windows to schedule or manage, and your semantic model stays current as the underlying lakehouse or warehouse data changes. For organizations running Microsoft Fabric, this makes Direct Lake the natural default for Power BI semantic models built on top of Fabric data sources. Kanerika’s data engineering work with Fabric and Power BI consistently shows that Direct Lake reduces the operational burden on data teams, since eliminating refresh pipelines removes a common failure point in enterprise reporting environments.

Question 13

What are the 5 layers of a data platform?

Answer

A modern data platform typically consists of five layers: ingestion, storage, processing, semantic/modeling, and consumption. The ingestion layer handles pulling raw data from source systems like databases, APIs, and SaaS applications. The storage layer organizes that data in repositories such as a data lake or lakehouse, where Microsoft Fabric’s OneLake fits directly. The processing layer transforms raw data into clean, structured formats through pipelines and dataflows. The semantic layer, which is where Direct Lake semantic models in Power BI live, defines business logic, measures, and relationships that make data meaningful to end users. Finally, the consumption layer is where analysts and decision-makers interact with the data through reports, dashboards, and self-service tools like Power BI. Understanding this stack matters because Direct Lake mode specifically bridges the storage and semantic layers. Instead of importing data or querying through a relational engine, Direct Lake reads Parquet files from OneLake directly into the in-memory engine, cutting out intermediate steps. This makes the semantic layer more responsive and reduces data movement across the platform. Organizations building on Microsoft Fabric benefit most from this architecture when their storage layer is already structured around Delta tables in OneLake, allowing the semantic model to stay current without scheduled refreshes.

Question 14

What is an example of a semantic model?

Answer

A semantic model in Power BI is a structured layer that defines how raw data is organized, related, and interpreted for reporting for example, a sales semantic model that connects a fact table of transactions to dimension tables for customers, products, dates, and regions, with measures like total revenue, year-over-year growth, and average order value built in. In a Direct Lake setup on Microsoft Fabric, this same sales model would read directly from Delta tables stored in OneLake, bypassing the need to import or cache data. Users querying a report would get real-time access to the latest transaction data without a scheduled refresh, while still benefiting from pre-defined relationships, calculated columns, and DAX measures that make the data meaningful and consistent across all reports. This separation of data logic from raw storage is what makes semantic models valuable analysts build reports on top of a governed, reusable model rather than writing custom queries against raw tables each time. Teams managing large-scale data environments, like those Kanerika works with on Fabric and Power BI implementations, typically centralize these models so that definitions like active customer or net revenue stay consistent across the entire organization rather than varying report by report.

Question 15

Why is it called a semantic model?

Answer

A semantic model is called semantic because it defines the meaning and relationships behind your data, not just the data itself. The word semantic refers to meaning, and that is exactly what this layer provides it translates raw tables and columns into business-meaningful concepts like revenue, customer lifetime value, or regional performance. In Power BI, a semantic model sits between your data source and your reports, storing measures, hierarchies, relationships, and business logic that give context to otherwise plain numbers. When a report asks what is total sales by region, the semantic model already understands what total sales means and how regions relate to transactions so every report built on top of it gets consistent, governed answers. Microsoft rebranded Power BI datasets to semantic models in 2023 to better reflect this purpose. The name shift signals that these objects are not just data containers but active layers of business intelligence logic. In Direct Lake mode specifically, the semantic model reads data directly from OneLake without importing it, making the semantic layer even more important because it carries all the calculation and relationship logic that transforms raw lakehouse files into analysis-ready business metrics.

Question 16

What is a data lake vs lakehouse?

Answer

A data lake stores raw, unstructured, or semi-structured data in its native format, while a lakehouse combines the storage flexibility of a data lake with the structured query and transaction capabilities of a data warehouse. Data lakes are built for storing massive volumes of data cheaply, but querying them directly is slow and complex. Lakehouses solve this by adding a metadata and transaction layer technologies like Delta Lake or Apache Iceberg on top of the raw storage, enabling fast SQL queries, ACID transactions, and schema enforcement without moving data to a separate warehouse. In the context of Power BI Direct Lake semantic models, the lakehouse architecture is what makes the feature practical. Direct Lake connects directly to OneLake files (Microsoft’s unified storage layer built on lakehouse principles), reading Parquet files without importing or caching data first. This gives you near-real-time data access with performance closer to import mode than traditional DirectQuery. For teams building Power BI solutions on Microsoft Fabric, understanding this distinction matters because your data needs to live in a Fabric lakehouse or warehouse to take advantage of Direct Lake. Organizations working with Kanerika on Fabric implementations typically start by assessing whether their existing data lake assets can be migrated or mirrored into OneLake to unlock this performance benefit.

Question 17

Is databricks a semantic layer?

Answer

Databricks is not a semantic layer, but it can serve as the data foundation that a semantic layer sits on top of. Databricks is a unified data analytics platform built around Apache Spark, primarily used for data engineering, machine learning, and large-scale data processing. It stores and processes data but does not define business metrics, relationships, or reusable logic the way a semantic layer does. A semantic layer, by contrast, abstracts raw data into business-friendly terms, centralized KPI definitions, and consistent metric logic that analytics tools can query. In the context of Power BI and Direct Lake, the semantic model in Power BI acts as the semantic layer, while Databricks or Microsoft Fabric lakehouses serve as the underlying data storage and compute engine. That said, Databricks does offer Unity Catalog, which provides governance, lineage, and some metadata management capabilities that overlap with semantic layer functions. Some organizations also use dedicated semantic layer tools like AtScale or dbt metrics on top of Databricks to create a true business-logic abstraction before data reaches Power BI. The practical distinction matters when designing your architecture: Databricks handles data transformation and storage, while the semantic model in Power BI handles business definitions and reporting logic. Getting this separation right is critical for building scalable, maintainable Direct Lake solutions.

Question 18

Why use semantic models?

Answer

Semantic models in Power BI serve as a centralized, reusable data layer that standardizes business logic, metrics, and relationships across your entire organization. Instead of every report author building their own calculations or interpreting data differently, a single semantic model ensures everyone works from the same definitions whether that’s revenue, churn rate, or headcount. From a practical standpoint, semantic models reduce redundancy. Analysts connect to one trusted model rather than duplicating transformation logic across dozens of reports. This makes maintenance far easier: update a measure once, and every connected report reflects the change automatically. For Direct Lake specifically, semantic models unlock real-time querying against large datasets stored in OneLake without the need to import or cache data. This combines the performance benefits of in-memory analysis with the freshness of direct query, making it well-suited for high-volume analytical workloads. Semantic models also enforce governance by centralizing row-level security, data lineage, and access controls in one place. Organizations dealing with compliance requirements benefit from this structure because permissions and data policies are managed consistently rather than scattered across individual reports. Teams looking to scale their Power BI environment find semantic models essential for maintaining consistency as the number of reports, dashboards, and users grows. Kanerika’s approach to Power BI implementations focuses on building these reusable model layers early, which prevents the technical debt that accumulates when teams skip this foundation and build report-by-report instead.

Question 19

What is the difference between semantic model and LLM?

Answer

A semantic model and a large language model (LLM) are entirely different technologies that serve different purposes in data and AI workflows. A semantic model in Power BI is a structured layer that defines how business data is organized, related, and calculated. It maps raw data to business-friendly terms, enforces metrics consistency, and allows reports to query data with a shared understanding of definitions like revenue or active customers. Direct Lake semantic models take this further by reading data directly from OneLake storage in Microsoft Fabric, eliminating the need for data imports or caching. An LLM, by contrast, is a type of generative AI trained on large text datasets to understand and produce human language. Models like GPT-4 or Claude are used for tasks like summarization, code generation, and natural language interfaces. They do not inherently understand your business data or enforce metric definitions. Where the two can intersect is in natural language querying. An LLM can be used as a conversational interface that translates plain-language questions into queries against a semantic model, giving business users a way to explore data without writing DAX or SQL. The semantic model ensures the LLM’s responses are grounded in accurate, governed business logic rather than hallucinated numbers. Organizations building intelligent analytics platforms often combine both layers, using semantic models for data governance and LLMs for natural language accessibility. Kanerika helps clients architect these integrated solutions using Microsoft Fabric, Power BI, and AI tooling to connect governed data with generative AI interfaces.

Question 20

Can you use dax in direct query?

Answer

Yes, you can use DAX in Direct Query mode in Power BI, but with notable limitations compared to Import mode. Many DAX functions work normally, but those requiring data to be cached or iterated in memory such as certain time intelligence functions like DATESYTD or DATEADD are either unsupported or return errors because Direct Query doesn’t load data into the in-memory engine. In Direct Query, DAX measures are translated into native SQL queries sent to the underlying data source. This means the source database executes the logic, not the Power BI engine. If a DAX function can’t be converted to an equivalent SQL expression, it simply won’t work. For Direct Lake semantic models specifically, the behavior is different. Direct Lake uses VertiPaq-style in-memory processing from OneLake parquet files, so it supports a much broader range of DAX functions than traditional Direct Query. This makes Direct Lake a stronger option when you need complex DAX alongside large-scale data without the function restrictions Direct Query imposes. Practical tips for working with DAX in Direct Query include keeping measures simple and avoiding row-by-row iteration functions like SUMX over large tables, testing each measure against your specific data source since compatibility varies by connector, and checking Microsoft’s documented list of unsupported DAX functions for your source type. If your reporting logic depends heavily on advanced DAX, Direct Lake or Import mode will generally give you more flexibility and consistent results.

Question 21

Does Direct Lake support RLS?

Answer

Direct Lake does support row-level security (RLS), but with an important limitation: when RLS is applied to a Direct Lake semantic model, the engine automatically falls back to DirectQuery mode for users subject to those security rules. This fallback happens because enforcing row-level filters requires querying the underlying data source directly rather than reading from the in-memory Delta tables in OneLake. For users who are not subject to any RLS rules, such as admins or unrestricted roles, the model continues to operate in full Direct Lake mode with all its performance benefits. Only the filtered users experience the DirectQuery fallback, which means slower query performance compared to standard Direct Lake behavior. To minimize this performance impact, you can use object-level security instead of RLS where your use case allows it, since object-level security does not trigger the fallback. If RLS is essential, optimizing your underlying Delta tables and ensuring your Fabric capacity is appropriately sized will help reduce the performance gap during fallback scenarios.

Feature	Import Mode	DirectQuery	Direct Lake (New)
Data Refresh Needed	Yes	No	No
Performance	Fast (cached data)	Can be slow (live calls)	Fast (live from OneLake)
Multi-source Modeling	Possible but messy	Limited and rigid	Yes, built-in support
Transformation Support	Full via Power Query	Limited	None (for now)
Offline Availability	Yes	No	No
Data Duplication	Yes	No	No
Data Size Limits	File-based constraints	Backend limits apply	Unlimited (live model)

AI Services

Data Services

FLIP Platform

A game-changing low code/no code, self-service DataOps platform.

AI Agents

AI for Enterprise

Tools

Resources

Partners