Microsoft will introduce a unified SQL pool configuration model for Fabric Data Warehouse, with API changes starting by mid-December 2026 and a new default for workspaces from January 2027. The change removes the separate built-in and custom pool modes, so administrators and API clients manage SQL pools through one model across the Fabric portal and REST APIs.
SQL pools control how Fabric Data Warehouse allocates compute across workloads in a workspace. Today, Fabric represents pool configurations differently depending on whether the workspace uses the built-in or custom pool model. Built-in autonomous workload management separates SELECT and non-SELECT workloads, while custom SQL pools let administrators define isolation boundaries, classifiers and maximum resource percentages.
Existing workspaces keep active behaviour
Existing workspaces do not need to migrate or reconfigure SQL pools for the unified model. Active SQL pool configurations and workload behaviour remain unchanged.
The change affects inactive configurations that were previously submitted but are not in effect. After unification, those inactive configurations will no longer appear in the UI or in GET API responses.
API changes for integrations
By mid-December 2026, applications should stop relying on customSQLPoolsEnabled to retrieve inactive pool configurations. GET responses will return only the effective configuration for the workspace.
Before the January 2027 rollout, clients should also remove logic that branches between built-in and custom mode. The PATCH request will no longer include customSQLPoolsEnabled; clients will manage SQL pools directly through the configuration payload, while the SQL pool configuration payload itself remains the same.
This matters for portals, automation scripts and governance tools that display or compare SQL pool state. If those tools expect inactive custom configurations to be returned, they need to change to read and render only the effective configuration.
New workspace defaults
Beginning January 2027, new workspaces will use a unified default configuration with a single read-optimised SQL pool. That pool has access to 100% of available compute resources to serve all workloads, and Optimize for Reads is enabled by default.
For new workspaces, SELECT and non-SELECT workloads can each access up to 100% of available compute, compared with the current default allocation of 50% for each workload type. Query or ingestion work may complete sooner, but compute consumption can also rise depending on workload patterns and resource use.
Administrators can limit consumption by assigning smaller maximum resource percentages to individual pools. For ingestion-heavy workloads with limited cache reuse, the Optimize for Reads setting should be reviewed and may need to be turned off. When configurable cache cooldown becomes available, reducing the default five-minute cooldown can reduce the time compute remains allocated after activity.
Operational checks
Current custom SQL pool documentation lists statement type, application name and application name regular expression as classifier options. It also states that a workspace can have up to eight custom SQL pools, and that all custom SQL pools in a workspace must use the same classifier type.
Monitoring remains part of the operational work. The queryinsights.sql_pool_insights view tracks resource allocation, configuration changes and periods when pools are under pressure, which gives administrators a way to compare allocation choices with observed behaviour.
Choosing how Fabric SQL pools allocate compute, how API clients read effective configurations and how read-optimised defaults affect consumption are practical questions for ECS's Data topic, alongside Microsoft Fabric, Power BI, SQL Server and Dataverse. Sessions and workshops give attendees room to compare configuration patterns, migration experience and capacity management decisions from real Fabric environments. Attendees can bring current workspace designs and API assumptions for discussion before committing them to production automation.
This article was written by the ECS editorial team with the assistance of Amal Agent, run.events' AI assistant, which supported the research, drafting and proofreading.