Dynamic SQL Pools in Warehouse
Custom SQL Pools is now in preview, but I see a limitation in the sense that you cannot allocate more than 100% capacity to all pools. I would like to see the ability to create multiple pools and assign pools a priority. I am considering an example where I have heavy ETL workloads that run late at night that I would want to grant 100% of resources with a medium priority. At the same time, I want an intraday ETL pool at uses 35% with a high priority and a pool for reporting that is allocated up to 70% with a medium priority. In this configuration, we have pools subscribing to more than 100%, but the scheduler could grant nodes based on priority.White Cursor
Could you make the mouse pointer black in the lakehouse/warehouse query windows? Every time I perform a function the mouse pointer turns white for 5-30 seconds, which makes it impossible to do anything else while you're waiting for it to turn black again because you cannot see it. It is not just frustrating, but a complete waste of man hours. As a matter of fact, it is doing it in this window as I type.
Fabric app end-to-end user identity delegation for Warehouse RLS
When a Fabric App uses the multi-user XMLA model, the service identity is used to query the SQL Warehouse. As a result, any Warehouse RLS is evaluated against the service identity rather than the actual signed-in user. This significantly limits the value of Warehouse-level security in multi-user application scenarios. While security can be implemented outside the Warehouse, the available authentication and authorization options are much more limited than the rules and policies that can be defined directly at the data layer. I'd like to see support for end-to-end user identity delegation, allowing the effective user identity to flow through Fabric Apps, semantic models, and into the Warehouse. This would enable RLS and access decisions to be based on the real user while still supporting service identities for application execution. Enforcing security where the data lives would simplify governance, reduce duplicated security logic, and allow organizations to fully leverage Warehouse-level security capabilities in enterprise deployments. short description: Ensure Warehouse RLS and security policies are evaluated using the signed-in user identity, not the service identity.
Settings to Auto Delete SQL Queries
SQL queries in a Fabric Warehouse, Lakehouse, etc. save automatically with a generic name, e.g. SQL query 1. While there have been improvements to allow for bulk deleting, I would suggest adding the following functionality: Allow users to choose between automatically saving new queries (as it works now) or automatically deleting any unsaved queries after they're closed. A quick button to 'delete unnamed queries', which would leave any queries which have been renamed or saved with an actual name, deleting any which have just been saved with the generic 'SQL query 1' type name. Allow users to select a retention period and automatically delete unnamed queries after this time, e.g. after 1 day / 1 week.
Environment Copy/Duplicate
Why is there still no single tool to copy/duplicate an environment. Its seems that an MCP nor Deployment Pipelines can do all the necessary tasks to copy the whole of an env in its entirety, ie all artefacts and warehouses/lakehouses etc such for either 1) creation of a new environment like Pre Prod, Staging or to quickly replicate an environment. I know that using a combo of tools it can be done. But surely Fabric has matured enough for this to be available by now or have i missed something ?
Microsoft Fabric needs more granular RBAC for Workspace roles
Microsoft Fabric needs more granular RBAC for Workspace roles One of the major limitations we are running into with Microsoft Fabric is the lack of granular RBAC (Role-Based Access Control) at the workspace level, particularly for production support scenarios. A common enterprise requirement is for an L2 Production Support team to be able to: View the implementation/code of artifacts such as Notebooks and Data Pipelines Execute/run those artifacts when troubleshooting or responding to production incidents Not modify, edit, or overwrite the code or configuration Today, the built-in Fabric workspace roles don't provide a clean way to implement this separation of duties. A Viewer role is too restrictive, while roles that provide the required execution capabilities also provide broader write/edit permissions. This creates an unnecessary security and operational gap in production environments. Fabric needs a more mature RBAC model where organizations can either: Have additional built-in roles that separate Read, Execute, Edit, Create, Delete, Share, and Administer permissions, or preferably, Create custom workspace roles and explicitly define the permissions granted to each role. For example, we should be able to create a role such as: Production L2 Support View workspace: Yes View Notebook/Pipeline code: Yes Execute Notebook/Pipeline: Yes View run history/logs: Yes Edit artifact: No Create artifact: No Delete artifact: No Change permissions: No This is standard RBAC/separation-of-duties functionality expected from an enterprise data and analytics platform. Fabric's authorization model should not be constrained by role concepts inherited from Power BI. Fabric now covers data engineering, data integration, data science, warehousing, real-time workloads, and production data pipelines. The security model needs to evolve accordingly. Request: Please introduce granular permissions and custom RBAC roles for Fabric workspaces, particularly the ability to independently control view, execute, edit, create, delete, and administrative permissions. This would make it significantly easier for enterprises to implement least-privilege access and proper separation of duties between development teams and production support teams.
Fabric Warehouse - Deployment Pipeline - Fix ALTER TABLE issue
Currently, when adding a column to a Warehouse table in Dev workspace, and then using Fabric Deployment Pipeline to deploy the Warehouse to Test and Prod workspace, the existing table gets dropped and recreated with the added column. Unfortunately, this leads to all existing data in the table in Test and Prod getting lost. Please fix this issue. I believe this issue is documented here: Currently, if you use ALTER TABLE to add a constraint or column in the database project, the table will be dropped and recreated when deploying, resulting in data loss. https://learn.microsoft.com/en-us/fabric/data-warehouse/source-control#limitations-for-deployment-pipelinesAbout "Download SQL database project" and fix the downloaded project
1. The sqlproj must be fixed, it is downloaded without the xml markup line <?xml version="1.0" encoding="utf-8"> 2. The sdk must be updated: Actual: <Sdk Name="Microsoft.Build.Sql" Version="0.1.19-preview" /> Must be: <Sdk Name="Microsoft.Build.Sql" Version="2.2.0" /> After this two fixes are done, it builds and deploy pretty fine.Increase column limit of 1024 on sql analytic endpoint and warehouse
Currently there is 1024 max column limit in SQL analytic endpoint and warehouse fabric items. We can view delta lake tables in lakehouse but causes issues with table not syncing to SQL analytic Endpoint. I see the following error message when trying to sync the in SQL analytic endpoint. Corrective Action: Try to split the dataset into multiple tables that have up to 1024 columns. Can this be increased since underlying storage delta parquet doesn't carry this limitation?
The Delta Log of the Warehouse contains fewer items than the Lakehouse.
Lakehouse Delta Log contains a variety of items. However, there are only a few items included in the Warehouse Delta Log. Since operation / operationParameter / isolationLevel / operationMetrics are useful information to verify transactions, we would like this information to be included in the Delta Log of the Warehouse.
