Unifying SQL Pools: Upcoming changes to UI and APIs

SQL pools are Fabric Data Warehouse’s built-in workload management capability. They help administrators organize workloads and control how compute resources are allocated across them.

SQL pool configurations are represented differently depending on whether a workspace uses the built-in or custom pool model. With unified SQL pools, we’re removing that distinction and representing all pools through a single configuration model across the UI and APIs. This removes the need to switch between built-in and custom modes, making SQL pool configurations easier to understand and manage consistently across the UI and APIs.

What's changing and when 

This blog provides advance notice of upcoming changes to SQL pool configuration management in Fabric Data Warehouse. We're introducing a unified configuration model that removes the distinction between built-in and custom SQL pools. 

• By mid-December 2026: Customers should stop relying on customSQLPoolsEnabled flag to retrieve previously submitted inactive pool configurations. With unification, GET APIs will return only effective configurations, and inactive configurations will no longer be surfaced in the UI or APIs. 

• Beginning January 2027: New workspaces will use a unified default configuration with a single read-optimized SQL pool that has access to 100% of available compute resources to serve all workloads. Existing workspaces will retain their active configurations and workload behavior.

• Updated documentation will be published alongside the January rollout. 

What this means for customers 

Unified SQL pools simplify the configuration experience without requiring existing customers to migrate or reconfigure their SQL pools. 

Performance and cost considerations for new workspaces 

The following performance and cost implications apply only to new workspaces. Existing workspaces will retain their current SQL pool configurations and workload behavior. 

With unified SQL pools, new workspaces will allow SELECT and non-SELECT workloads to access up to 100% of available compute resources, compared to the current default allocation of 50% for each workload type. 

• SELECT workloads: Queries can access up to 100% of available compute instead of 50%, potentially improving performance but also increasing compute consumption. 

• Non-SELECT workloads: Operations such as data ingestion can also access up to 100% of available compute , potentially completing faster but consuming more compute. 

Actual performance and cost impact will depend on workload patterns and resource utilization. To manage consumption, customers can: 

• Allocate smaller resource percentages to individual pools to limit their maximum potential compute consumption. 

• Disabling Optimize for Reads: For ingestion-heavy workloads with limited cache reuse, consider turning off Optimize for Reads to avoid unnecessary cache-related consumption. 

• Reducing cache cooldown: Once configurable cache cooldown becomes available , shorten the default five-minute cooldown (for example, to one minute) through the UI or API to reduce the time compute remains allocated after activity. 

What API consumers should update  

If you integrate with SQL Pools REST APIs, review your client logic before the unified SQL pools rollout: 

• By mid-December 2026: Stop relying on customSQLPoolsEnabled flag to retrieve previously submitted inactive configurations. Update your clients to read and render only the effective configuration returned by GET. 

• Before the January 2027 rollout: Remove logic that branches on built-in versus custom mode, and prepare for the removal of customSQLPoolsEnabled from PATCH requests. 

Changes to GET API responses 

With unified SQL pools, GET responses will reflect only the configuration currently in effect for the workspace.  Previously submitted custom pool configurations with customSQLPoolsEnabled was false that are not active, will no longer be returned by the API or displayed in the UI. 

Changes to PATCH API

Now, the PATCH API uses the customSQLPoolsEnabled flag to distinguish between built-in and custom SQL pool configurations. With unification, this flag will be removed from the PATCH request, and clients will manage SQL pools directly through the configuration payload. 

The examples below illustrate this change. The only difference is the removal of customSQLPoolsEnabled ; the SQL pool configuration payload remains the same. 

Before unification (current behavior): 

PATCH https://api.fabric.microsoft.com/v1/workspaces/<workspace id> /warehouses/sqlPoolsConfiguration

{ 
  "customSQLPoolsEnabled": true, 
  "customSQLPools": [ 
    { 
      "name": "ETL", 
      "isDefault": false, 
      "maxResourcePercentage": 20, 
      "optimizeForReads": false, 
      "classifier": { 
        "type": "Application Name", 
        "value": [ 
          "ETL", 
          "Load", 
          "Pipeline" 
        ] 
      } 
    }
    ]
} 

After unification (proposed behavior):

PATCH https://api.fabric.microsoft.com/v1/workspaces/<workspace id> /warehouses/sqlPoolsConfiguration

{ 
  "customSQLPools": [ 
    { 
      "name": "ETL", 
      "isDefault": false, 
      "maxResourcePercentage": 20, 
      "optimizeForReads": false, 
      "classifier": { 
        "type": "Application Name", 
        "value": [ 
          "ETL", 
          "Load", 
          "Pipeline" 
        ] 
      } 
    }
    ]
} 

Next steps 

Existing workspace configurations will remain unchanged, but API consumers should review dependencies on customSQLPoolsEnabled  flag and prepare for the unified model. For new workspaces, consider customizing pool allocations and 'Optimize for Reads' settings based on performance and cost requirements.

Refer to the SQL Pools REST API documentation for the current API behavior. Updated documentation will be published alongside the rollout.