OneLake Security support for Fabric Warehouse - planned roadmap or intentional limitation?
I'm evaluating Direct Lake on OneLake for enterprise semantic models that span multiple Fabric items and workspaces. From the current documentation, OneLake Security appears to support: Lakehouses Mirrored Databases Mirrored Catalogs However, Fabric Warehouses are not listed as supported OneLake Security items. This raises a challenge for organizations that have adopted a warehouse-centric architecture. Another challenge is security for Direct Lake semantic models. My goal is to keep semantic models in Direct Lake mode while granting semantic model developers restricted access only to specific tables within specific Warehouse. Today, this appears difficult without granting broader permissions (such as ReadAll access), and OneLake Security is not currently listed as supporting Warehouse items. Ideally, I would like a Warehouse-based security model, Direct Lake on OneLake semantic models to function without exposing the entire Warehouse. For example: Wh_Fico Wh_Sales Wh_Scm Wh_Master Today, Warehouses support SQL-based security features such as: Object Level Security (OLS) Column Level Security (CLS) Row Level Security (RLS) GRANT / DENY permissions However, Direct Lake on OneLake is positioned as the preferred option for semantic models spanning multiple Fabric items, while SQL-based security is documented as a reason to remain on Direct Lake on SQL. My questions are: Is the absence of Warehouse support in OneLake Security an intentional product design decision? Is there any roadmap to enable OneLake Security roles directly on Fabric Warehouses? If Warehouse support is not planned, what is the recommended long-term architecture for warehouse-centric customers who want: Direct Lake on OneLake Cross-workspace semantic models Centralized table/column/row security Should customers expect to introduce a Lakehouse layer purely for OneLake Security, or will OneLake Security eventually become available directly on Warehouse items? Any guidance from the product team would be appreciated.Best approach(es) to refresh Dev Warehouse from Prod Warehouse (Read-Write Copy) in Microsoft Fabric
We are currently evaluating the best practices for refreshing a Development Data Warehouse using data from a Production Data Warehouse within the same Fabric tenant. We have evaluated a few approaches based on the use case: Read-Only Access (Zero-Copy): If Dev only needs read access to Prod data, using OneLake Shortcuts is the clear choice. It provides instantaneous access with zero data duplication, no storage overhead, and minimal setup effort. Read-Write Access (Full Schema & Data Copy): If Dev requires a Read-Write copy (allowing developers to run DML operations like UPDATE, INSERT, or DELETE without impacting Production), our current options seem to be: Fabric Data Pipelines (Copy Activity): Scheduled or trigger-based pipelines to pull data from Prod to Dev. Cross-Database Querying / CTAS: Running T-SQL (CREATE TABLE AS SELECT ...) across workspaces. The Challenge: Both Read-Write options (Pipelines and CTAS) can become cumbersome to set up and maintain, especially as datasets grow. Additionally, duplicating large volumes of data incurs extra storage and CU (Capacity Unit) processing costs. Was wondering if there are better, more efficient options available in Microsoft Fabric to maintain or periodically refresh a Read-Write copy of a Warehouse in a Dev workspace? Is Table Cloning / Zero-Copy Clone supported or planned for cross-workspace scenarios? How are others managing periodic Dev environment refreshes from Prod without creating heavy data copy pipelines?Warehouse Scaling
Hi everyone, As data volumes continue to grow, I'd like to understand how organizations scale Microsoft Fabric Data Warehouse solutions. Which techniques have had the biggest impact on: Query performance Cost optimization Data modeling Concurrent workloads Long-term maintenance Any lessons learned from production deployments would be greatly appreciated.
Request for Help: Warehouse Update Step Fails Between 3:30 AM and 7:00 AM
Hi All, We recently changed our Fabric capacity start time from 7:00 AM to 3:00 AM, and I updated the SQL Server to Fabric Lakehouse data ingestion pipeline to start at 3:30 AM. At the end of the pipeline for each table ingestion, there is a step that updates the Latest Update Date and Time in to the warehouse. However, this step consistently fails until 7:00 AM. After 7:00 AM, the same process runs successfully without any issues. I've attached an image that illustrates the behavior more clearly. Could anyone help identify what might be causing this? Is there any time-based restriction, service dependency, or configuration that needs to be enabled before 7:00 AM? Any insights would be greatly appreciated. Thanks!
Deployment Pipeline does not rebind Direct Lake semantic model to target Warehouse
Deployment Pipeline does not rebind Direct Lake semantic model to target Warehouse Environment Microsoft Fabric Deployment Pipelines Semantic Model storage mode: Direct Lake Data source type: Warehouse Scenario DEV Workspace Sandbox Sandbox ├─ Warehouse └─ Semantic Model TEST Workspace Sandbox Test Sandbox Test Steps to reproduce Create a new Deployment Pipeline. Assign the DEV workspace (Sandbox). Assign the TEST workspace (Sandbox Test). Deploy both the Warehouse and the Semantic Model from DEV to TEST. Verify the deployment status. Result Both artifacts show: Warehouse -> Same as source Semantic Model -> Same as source The semantic model is successfully deployed to the TEST workspace. However, when opening the semantic model and inspecting a table, the metadata shows: Storage mode: Direct Lake Data source type: Warehouse Workspace: Sandbox instead of: Workspace: Sandbox Test Additionally, the Lineage View shows that the Semantic Model located in the TEST workspace is still connected to the Warehouse located in the DEV workspace. Expected behavior After deployment, the Direct Lake semantic model in TEST should automatically bind to the Warehouse deployed in the TEST workspace: Sandbox Test ├─ Warehouse └─ Semantic Model Additional validation performed Created a completely new Deployment Pipeline. Created a completely new TEST workspace. Confirmed Warehouse deployment succeeded. Confirmed Warehouse status = "Same as source". Confirmed Semantic Model status = "Same as source". Refreshed the Semantic Model after deployment. Verified the Lineage View. Verified the table metadata inside the Semantic Model. The issue persists. Additional information The Semantic Model was created directly in Microsoft Fabric from the Warehouse using Direct Lake mode. It was not published from Power BI Desktop. Question Is automatic rebinding of Direct Lake Semantic Models to the target Warehouse currently supported by Deployment Pipelines, or is manual rebinding required after deployment? If manual rebinding is required, what is the recommended approach for DEV → TEST → PROD deployments?
Designing a Star Schema Data Warehouse for a School in MS Fabric
I have a question regarding the design of a star schema for a school in MS Fabric. Unlike typical business scenarios such as internet and retail sales, the assessment data requires many measurable columns. I've already created the following dimension tables: DimStudent, DimTime, DimSubject, DimClass, DimStaff. However, I am uncertain about the best approach to building fact tables. Source data set: Grade A=5, B=4, C=3, D=2, F=1 for analysis Approach 1: Single fact table DateKey, StudentKey, SubjectKey, ClassKey, CalculatedMark, CalculatedGrade, ModeratedMark, ModeratedGrade, Assessment1 to Assessment15, Profile1 to Profile15 This would result in a fact table with 38 or more columns. Approach 2: Multiple Fact Tables FactMark: DateKey, StudentKey, SubjectKey, ClassKey, CalculatedMark, CalculatedGrade, ModeratedMark, ModeratedGrade FactAssessment: DateKey, StudentKey, SubjectKey, ClassKey, Assessment1 to Assessment15 FactProfile: DateKey, StudentKey, SubjectKey, ClassKey, Profile1 to Profile15 Approach 3: Multiple Fact Tables with Associated Dimension Tables FactMark: DateKey, StudentKey, SubjectKey, ClassKey, CalculatedMark, CalculatedGrade, ModeratedMark, ModeratedGrade FactAssessment: DateKey, StudentKey, SubjectKey, ClassKey, AssessmentTypeKey, AssessmentValue FactProfile: DateKey, StudentKey, SubjectKey, ClassKey, ProfileTypeKey, ProfileValue DimAssessmentType: TypeKey, TypeDescription DimProfileType: TypeKey, ProfileDescription Approach 4: Single Fact Table with Associated Dimension Table FactSchoolAcademicResult: DateKey, StudentKey, SubjectKey, ClassKey, ResultType, ResultValue DimAcademicResultType: TypeKey, TypeDescription (This includes all result types such as marks, assessments, and profiles.) Which approach would be the best among these four, or do you have a better suggestion for my design?
