A Lakehouse Collation setting showing case sensitive vs non-case sensitive should be added to the exisitng lakehouse settings in Microsoft Fabric.  For years i've been able to change collations on a database on on-prem SQL and am able to re-populate those data tables to reflect the new collation moving forward.  This should be an option in Microsoft Fabric in the lakehouse settings which should allow me to change a collation on an existing Lakehouse without having to create a brand new Lakehouse and have to completely recreate anything in it's lineage such as semantic models, reports, etc.  Seems like we could do this for the last 20+ years in SQL and should be able to do this using a Lakehouse easily as well. ... View more

When connecting to a semantic model currently, we have to use the workspace/lakehouse/warehouse unique id and semantic model unique id in order to analyze that semantic model.  Instead of using those unique ids attached to a very specific semantic model we should be able to have the ability to customize those unique ids to a static customizable user friendly names for ease of use and the best customer experience.  Currently if I want to analyze a semantic model in Microsoft Excel or another methodology, if I have to connect to that model with the unique workspace/warehouse/lakehouse id and unique semantic model id, why can't I use the user facing workspace name, lakehouse name and semantic model name?  Why are we using GUIDs in 2025?   Additionally, if I have a new model that needs to replace an existing model, I should be able to replace or rename that model to the existing model name and it should inherit the current model's lineage vs recreating and redeploying all the associated lineage items to the new model.  This would save so much development time it's ridiculous that there is no solution for this currently. ... View more

Currently I need to use Tabular Editor to make modifications to the collation assigned with any semantic models I create in Microsoft Fabric.  These collations appear to be a random bug and do not always inherit my lakehouse collation.  This causes issues when my users/customers try to analyze a semantic model inside of Microsoft Excel and try to filter data for a specific data value in the model that is case sensitive.  A button should be added to the semantic models settings that turns case sensitivity on or off.  As a work around, I am currently using Tabular editor to modify a semantic model and deploy a copy to Fabric.  This does not allow me to modify the existing semantic model, but create a new semantic model with the collation I want.  This should be an easy add/fix that should already be in Microsoft Fabric since it's kind of already in a 3rd party tool. ... View more

The business needs Excel to perform on Fabric   The Problem: Unoptimized Capacity Consumption and Performance Bottlenecks While Excel's live connection to Fabric Semantic Models is a key feature, it currently presents a significant challenge for enterprise-level deployments, primarily related to performance and the unoptimized use of Fabric capacity. The core issue is that the current connection method, which relies on the XMLA endpoint and MDX query translation, leads to:  * Excessive Capacity Consumption: Every user interaction—from dragging a field to applying a filter—generates an independent, and often verbose, MDX query that is translated and executed. This constant, unoptimized querying on a per-user, per-click basis results in a high number of interactive queries, which are the most expensive type in Fabric capacity.  * Poor User Performance: As a result of the unoptimized queries, users experience frustratingly slow response times. A simple action that should be near-instantaneous can take several seconds to complete, especially with complex semantic models and multiple concurrent users. This degrades the user experience and can lead to a lack of trust in the centralized data model. The Proposed Enhancement: A Modern, Optimized Connection Layer We request the development of a new, modernized connection layer for Excel that is purpose-built for Fabric Semantic Models. This would move beyond the legacy MDX translation approach and provide a more intelligent and efficient way for Excel to interact with the service. Key features of this enhanced connection layer should include:  * Smart Query Batching: Implement a mechanism to intelligently batch multiple user actions into a single, optimized query to the Fabric service. This would significantly reduce the number of interactive queries, lowering capacity consumption and improving performance.  * Native DAX Support: Instead of translating MDX to DAX on the server, allow Excel to generate optimized DAX queries directly from the client. This would eliminate a performance bottleneck and ensure that the queries are written in a way that best leverages the semantic model's structure.  * Improved User Experience: A faster, more responsive connection would dramatically improve the user experience, encouraging broader adoption of Fabric as the go-to platform for data analysis in conjunction with Excel. Business Impact: Unlocking True Enterprise Scalability This enhancement is not just a "nice-to-have"; it is critical for unlocking the true enterprise scalability of Microsoft Fabric. A modern, performant connection between the world's most popular spreadsheet tool and Microsoft's unified data platform would:  * Reduce TCO: By consuming capacity more efficiently, organizations can get more value from their Fabric investment and manage costs more effectively.  * Boost Productivity & Trust: Faster performance means business users can work more efficiently, building trust in the centralized data model and reducing reliance on manual, ad-hoc data sources.  * Strengthen the Microsoft Ecosystem: This would further cement the powerful synergy between Fabric and Office, demonstrating a seamless and high-performance experience for the millions of users who rely on both products daily. Summary: Everyone agrees, Excel is not going away. Optimizing Excel's connectivity to Fabric Semantic Models for capacity and performance is essential. We urge the Fabric team to prioritize the development of a modern, efficient connection layer that will not only solve current user frustrations but also enable organizations to confidently scale their analytics solutions. Fabric has gone miles beyond a reporting tool as it has evolved into Fabric, these changes fully fit within the scope of providing a robust end to end Analytics platform.     ... View more

With the rising adoption of Multi-Factor Authentication (MFA) across our organization and industry best practices, we are seeking a more robust and streamlined authentication method for connecting Power BI to Snowflake. Currently, Power BI primarily relies on username/password or OAuth 2.0 via Microsoft Entra ID. While these methods are functional, they can become cumbersome and less secure in MFA-enabled environments. We propose the implementation of RSA key pair authentication for Snowflake connections within Power BI. ... View more

Currently Dataverse is not available to use as a real-time data source. Adding Dataverse will allow dashboards for real-time views of Dataverse and other Power Platform data natively. Real-time dashboards previously supported dataverse data with power automate pushing to streaming datasets. This capability is now deprecated but not replaced.   ... View more

Hello, Currently, Power BI connects to Google Cloud Storage using HMAC credentials, which require manual key management and pose security and scalability challenges. I propose adding support for Workload Identity Federation (WIF) as an authentication method to enhance security, simplify credential management, and align with modern cloud identity practices. Advantages of WIF Authentication Improved Security: WIF eliminates the need for long-lived HMAC keys by using short-lived, automatically rotated tokens via identity providers. No Key Rotation Hassles: Credentials are federated dynamically, removing the need to manually rotate or store HMAC keys. Centralized Identity Management: Integrates with enterprise identity providers, enabling fine-grained access control and auditability. Scalability: Ideal for large-scale deployments where managing static keys becomes impractical. Compliance-Friendly: Supports modern security standards and helps meet compliance requirements for cloud-native environments. Limitations of HMAC Authentication Manual Key Management: Requires storing and rotating static access keys, which increases operational overhead. Security Risks: Static keys are vulnerable to leakage and misuse if not handled securely. Limited Integration: Does not integrate well with identity providers or support federated access models. Audit Complexity: Tracking access and usage is harder compared to federated identity systems. Conclusion Adding WIF support for Google Cloud Storage in Power BI would significantly improve security, reduce administrative burden, and align with best practices for cloud identity management. This enhancement would benefit organizations looking to modernize their data access architecture while maintaining robust governance.   Thanks, Surendhar ... View more

Based on https://community.fabric.microsoft.com/t5/Data-Engineering/Creating-a-Primary-Key-for-Lakehouse-Table/m-p/4742452#M10401 and based on error message that I'm receiving when creating keys from notebook (Table constraints (Primary and Foreign key) are not supported in V2 Datasource tables) seems that primary and foreign keys are not supported in Lakehouse. I believe that support for keys would be very useful and beneficial. The thing is that through the SQL analytics endpoint you can create them which is confusing so I contacted Microsoft to see what is the status and the response was: You're absolutely right—Microsoft Fabric currently has limited support for table constraints like primary and foreign keys. Here’s a summary of the current behavior and limitations: What Works: Primary keys can be defined only via the SQL Analytics Endpoint, using syntax like: ALTER TABLE MyTable ADD CONSTRAINT PK_MyTable PRIMARY KEY NONCLUSTERED (id) NOT ENFORCED; This allows you to register metadata constraints, which can be useful for documentation or downstream tools. Where Primary Keys Are Supported: Fabric SQL Database (distinct from Lakehouse) does support primary keys and foreign keys, similar to Azure SQL Database or SQL Server. However, even in Warehouse or SQL Analytics Endpoint, constraints like PRIMARY KEY, FOREIGN KEY, and UNIQUE are only supported when: NONCLUSTERED NOT ENFORCED Limitations: These constraints are not enforced—they do not prevent duplicates or ensure referential integrity. They are not supported in V2 Datasource tables, which is why attempts from notebooks result in the error: "Table constraints (Primary and Foreign key) are not supported in V2 Datasource table." Foreign keys and unique constraints follow the same pattern: metadata-only, not enforced. Known Issues Duplicate data can still be inserted, even if a primary key is defined. No enforcement during ingestion or transformation—you’ll need to handle integrity checks manually. Metadata APIs may not behave as expected (e.g., JDBC metadata queries may not return constraint info reliably). Microsoft has not officially announced full support for enforced constraints in Lakehouse tables. ... View more

Could Microsoft support SQLMesh project so that they provide good compatibility against Fabric warehouse and lakehouse (via Spark)? Could SqlMesh be added as Fabric native workload to get it as service since this kind of sql modeling functionality with web UI is missing? Add support for Microsoft Fabric · Issue #3374 · TobikoData/sqlmesh ... View more

The amount of compute which is charged for writebacks via Power Apps / UDF is not equal to the amount seen in the performance summary of the Fabric database and in general way to high. It becomes hard to understand what is causing CU spikes. We were told that because of the serverless architecture initial writes / reads take a couple of seconds (apx. 30s) to turn on the backend. After 15 min without interaction it scales down again. There is no way to see nor configure the compute usage of this. We would like to have more control in the process so simple write backs do not consume a ton of compute just for spinning up the server every time. Another big downside is that the end user need to wait a significant amount of time. Every UDF also needs to spin up if it was not used for 15 min.  We have an F4 Fabric Capacity in which we have created SQL DB workload. We also have a Power BI report in which a Power App is embedded. Power App reads data from SQL DB.   Every time end user interacts with the Power App, we see a spike in Capacity Metrics App.     It consumes almost half of the F4 capacity when Power App starts to read data from SQL DB.   This number is not aligning with the performance summary of the Fabric database. The memory tab only shows mb not compute usage.  ... View more

Overtime queries ran on a sql end point in a lake house build up in the my queries folder. They have to be individually deleted which can take a lot of time. There should be a way to delete all or highlight an delete multiple queries  ... View more

Currently complext type (json, struct) are supported in Onelake endpoint but not in SQL endpoint which prevents these important payload data types to be explored or used in Power BI. In big data world such fields are very common as many data generated through IoT are partially parsed in individual columns and raw json payload is left for future use or as on need basis. Before parquet - we use to store them as MapType which make them easy to further use. Adding this feature will do both - parsing those field easy for end user and also migration of existing data possible. ... View more

When provisioning a new Fabric SQL Database, after typing in the name I want, what I get is that name PLUS some random GUID characters. This just seems wrong. Nobody likes to have their stuff renamed. As I understand it by someone from Microsoft in the Fabric Community, this was done to ensure a unique name across the entirety of Microsoft Fabric. It would be nice if that was NOT a requirement. Maybe you can make it like Fabric Warehouses where it is the combination of the Tenant, Workspace, and Data Warehouse name that needs to be unique. ... View more

Dataflows need a way to reference a table as input, do a comparison and perform upserts on through the data destination in a single dataflow. Instead of having to rely on truncate/reload with replace or creating a stored procedure to do upserts on a staged table of changes. ... View more

When doing restore we always get a new database ID, Physical Name and SqlEndPoint, even if the database logical name is the same (eg restore over the top). This causes a massive increase in RTO as afer the restore all end points broke and configuration management had to be updated and re-tested. When doing a restore we need to have the ability to keep database exactly as it was, rather than always creating a clone. In a recent DR event it was 5 minutes to restore, but the 2 days before we stopped getting issues on end points and config change impact. ... View more

We are working on a migration project to Fabric and need to combine data from inside a SQL Database with data in a Lakehouse then write it to another table in the database. Due to T-SQL compatibility issue with Data Warehouse, we want to use a Fabric SQL database for the Gold layer. For example: SELECT * FROM SilverLakehouseDeltaTable x JOIN GoldDatabaseSQLTable y ON y.id = x.id   This should be part of a INSERT / UPDATE or MERGE such as:   INSERT INTO AnotherGoldDatabaseSQLTable (Columns) SELECT * FROM SilverLakehouseDeltaTable x JOIN GoldDatabaseSQLTable y ON y.id = x.id The ability to read data from OneLake in a Fabric SQL database would solve this problem. ... View more

I’m aware that Lakehouse Git integration in Microsoft Fabric is currently in preview. However, I believe some critical support is missing that would significantly enhance the usability and maturity of this feature.   At the moment, Git integration does not support versioning or tracking of critical Lakehouse objects such as: Tables Views User-defined functions Stored procedures These objects are essential components of any data platform, and not being able to track their definitions in source control limits our ability to: Perform proper code reviews Roll back changes Maintain consistent environments across workspaces Collaborate effectively in larger teams Follow DevSecOps best practices Suggestion: Please extend Git integration in Fabric Lakehouses to include full support for these objects. For example, warehouse git integration supports all of those objects. This enhancement would greatly improve DevOps practices in Fabric and align with modern data engineering workflows. ... View more

The core issue is the inability to directly access Microsoft Fabric SQL Databases from within Fabric Notebooks, despite the availability of JDBC and ODBC connection strings. The built-in notebook authentication token library appears to be missing Fabric SQL as an option. It does not currently appear possible (or at least not documented how) to access a Fabric SQL Server Database from within a Fabric Notebook. I see JDBC and ODBC connection strings, but these don't work apparently because the library to create authentication tokens is missing Fabric SQL as an option. Current Impact 1. Enterprises must create complex workarounds ("Rube Goldberg architectures") to establish basic data flows that leverage SQL Server 2. The platform fails to deliver on its "unified" promise, leading to a loss of faith in the Fabric brand 3. SQL Server's established strengths are not being leveraged effectively, further eroding trust that Fabric can deliver on enterprise data needs Summary This is a critical feature request that highlights a significant gap in Microsoft Fabric's platform integration. The inability to easily access Fabric SQL Databases from Fabric Notebooks undermines the platform's unified vision and creates unnecessary complexity for enterprise users. The request is well-justified, technically feasible, and would bring significant value to the platform. ... View more

It would be great if there were a possibility to call a SQL Database stored procedures directly from a Data Warehouse stored procedures. A use case for this would be e.g. logging activities and events during ETL loads. ... View more