Fabric Ideas

Oviwan · ‎12-04-2025

Description: Currently, when replicating tables from a SQL database to the SQL Analytics endpoint in Microsoft Fabric, all tables are included by default. However, not all tables are needed in the analytics endpoint. This creates unnecessary overhead and, in some cases, leads to lock situations in the SQL database during replication for certain tables. Problem: Some tables are not required in the analytics endpoint. Replication of these tables can cause locking issues in the source SQL database. There is no built-in mechanism to exclude specific tables from replication. Proposed Solution: Introduce functionality to exclude specific tables from replication. This should include: Explicit Table Exclusion: Ability to define a list of tables to exclude. Pattern-Based Exclusion: Support for regex-based patterns to exclude tables dynamically. Example: Exclude all tables ending with __b. Regex equivalent: .*__b$ Benefits: Reduces unnecessary replication overhead. Prevents lock situations on source tables. Provides flexibility for administrators to manage replication scope efficiently.

BobDuffyIRL · ‎03-19-2025

Currently the server name for SQLDB (and DW) is a double GUID of {tenant-Id-workspace-id.}database.fabric.microsoft.com This causes a lot of issues as 1. This is impossible to remember 2. We ahve no way to distinguish test from PRD We request user frirnedly DNS Names like Prodata-Sales-DEV.database.fabric.microsoft.com This would help clearly label an worksapce as DEV or PRD and avoid confusion and make the platform easier to work with.,

Jappieduck · ‎11-25-2025

Our company wanted to migrate their data from an SQL Server database to Fabric. The database we wanted to migrate has a specific collation, in particular it is case sensitive. It would be nice if we could alter the collation of SQL Databases to make migration easier.

Anonymous · ‎07-22-2025

Please provide a ability to semealessly connect Fabric SQL Database using Pyspark and get the result as dataframe. It should be of similar syntax such as spark.read..... This will open lot of options. Thank you.

higgy7 · ‎04-22-2025

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

BobDuffyIRL · ‎03-19-2025

When we connect to the DB we have to enter the Database Name whgich is a GUID. Please make this database name equal to the same name as trhe SQL End Point and database name in Fabric. This imporves usability, and allows for the same 3 part TSQL to run on SQL DB v SQL End Point. At the moment we have different TSQL Statements if we query SQLDB v SQL End Point which is not optimum

todd_chittenden · ‎12-09-2024

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.

data_fab_weaver · ‎08-27-2025

I recently came across that scalar functions are now available in sql end points for warehouses and lakehouses however you are unable to call them within CTEs and other sql objects , please make this feature available

bob_duffy · ‎01-23-2025

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.

rob_carrol1 · ‎01-10-2025

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.

jboarman · ‎02-01-2025

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.

Vojtech_Dolejsi · ‎11-21-2024

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.

rob_carrol1 · ‎01-13-2025

It should be possible to query data in a Fabric Lakehouse directly in Fabric SQL database using T-SQL. For example I have the following scenario where I want to join data from a table in my Fabric SQL DB to a delta table in my lakehouse then insert the resultset into another table in my Azure SQL database: INSERT INTO AnotherGoldDatabaseSQLTable (Columns) SELECT * FROM SilverLakehouseDeltaTable x JOIN GoldDatabaseSQLTable y ON y.id = x.id This isn't currently possible with Fabric SQL Database.

filip_olason · ‎12-18-2024

There is currently no way to control the scaling of an SQL DB. There should be a way to limit the database from scaling above a certain size. And / or a way to set a fixed cost/size (similar to DTU purchasing model).

Anonymous · ‎12-08-2024

Currently, the collation sequence for Microsoft Fabric SQL Database is set to SQL_Latin1_General_CP1_CI_AS, which means that creating tables or column names in Japanese or other languages will result in garbled characters. We have also confirmed that it is currently not possible to change the collation sequence in Microsoft Fabric SQL Database. On the other hand, the collation sequence for Microsoft Fabric warehouses is set to Latin1_General_100_BIN2_UTF8, which we have confirmed will not result in garbled characters. Therefore, we believe that if we could change the collation sequence for Microsoft Fabric SQL Database, it would be possible to set it to Latin1_General_100_BIN2_UTF8, which would help prevent garbled characters.

mark_lobbezoo · ‎12-07-2024

Within Fabric SQL databases you can cross-database query in the warehouse connection. However cross-database querying from one live SQL database to another is not possible. It would be great to have this possibility with 3-part names: select* from [sqldatabase].[dbo].[table_A] By getting this migrating from on-prem SQL server or an Azure managed instance to Fabric will be easier.

pmscorca · ‎06-02-2025

Hi, I think it is very importante that the Fabric SQL database workload could support fully Power BI, also with Direct Lake mode, like it happens for a lakehouse or a warehouse. Fabric SQL database should be fully integrated in the Fabric platform. Thanks

garddolau · ‎02-27-2025

Tried using Fabric SQL database to hold the metadata tables for metadata driven ingestion. Fabric SQL Database is not supported as source in stored procedure activity in pipelines. We need to update log tables in our metadata db by using the stored procedure activity. Is adding Fabric SQL Database in stored procedure activity on roadmap soon? Without this option available Fabric SQL database is not a viable option to replace an Azure SQL DB at this time. Please prioritise this option, Fabric SQL database is available in the Data Pipeline lookup activity so hopefully not to much much effort to also add to stored procedure activity. Thanks

BillBreitenbach · ‎12-09-2024

Currently, databases are randomly assigned to a pool of logical servers and there is not a way to group databases under same logical server name. Please allow us to see all the SQL databases listed under the same logical server name. It would be ideal to create one connection to the server name. This eventually would make cross-database querying on the same server possible as well .

bob_duffy · ‎01-23-2025

We had a few incidents here replication either stopped completely after a data centre crash or had irrecoverable errors. In all cases we had to fully restore database or delete and start again. We need the following features to help support replication and have smoother recovery from failures Start replication on GUI and API Stop replication on GUI and by API (The existing SQLDB API works here for Fabric) Query replication state on GUI and by API Resync either one table or all tables on GUI or by API. These features would allow for recovery from issues without having to do full restores and reduce customers down time.

Share your ideas and vote for future features

Ability to Exclude Specific Tables from SQL Database Replication to SQL Analytics Endpoint

SQLDB and DW and LH - Allow friendly server Name (DNS)

Collate SQL Database

Connect Fabric SQL Database using Pyspark and get the result as dataframe

Method to bulk delete sql endpoint queries

Keep Database Name as Non GUID

Fabric SQL Database names: Remove GUID suffix

Enable scalar functions in ctes and other sql objects

maintain DatabaseID, Database Name and SqlEndPoint on a restore

Read Data from Lakehouse inside a Fabric SQL Database (using T-SQL)

Enable Connection from Fabric Notebook to Fabric SQL Database

Allow calls of Fabric SQL Database stored procedures from Data Warehouse

Read Data from Lakehouse inside a Fabric SQL Database (using T-SQL)

Add guardrails to SQL DB

How to deal with garbled characters in Microsoft Fabric SQL Database

Cross-database queries for live databases

Fabric SQL database has to support fully Power BI

Fabric SQL Database - Available via Data Pipeline Stored Procedure Activity

Allow multiple database to be seen under the same server

Improve Fabric SQLDB Replication Support

Helpful resources

Increase the REST API Limitation for tags

Prioritize Shortcuts to Sharepoint/OneDrive for On...

Add tagging functionality for reports in Power BI ...

Allow the ability to search for idea - this forum ...

Data Catalog integration in PowerBI Designer

FabCon is coming to Atlanta

Share your ideas and vote for future features

Helpful resources