Protect Performance and Reduce Surprise Costs with Default Warehouse

Default Warehouse, now generally available in Databricks SQL, allows administrators to specify which SQL warehouse is automatically selected for ad hoc experiences. Default Warehouse ensures that exploratory queries run on the right compute, at the right cost, without requiring the user to know which warehouse to pick.

Fewer accidental warehouse wake-ups, better workload isolation, and more predictable performance and spend.

The challenge with warehouse selection today

As Databricks SQL adoption grows, so does the number of warehouses in a workspace. Customers commonly provision different warehouses for ETL, BI, and ad hoc queries, sizing them (e.g., T-shirt sizes and max cluster count) as needed to achieve the required price/performance.

For production ETL and BI workloads, specific warehouses are tied to the relevant asset or tool. However, for ad hoc queries, no warehouse is pre-assigned, leaving users to select one manually. 

Without a configurable default, the system falls back to "Last Selected" behavior or alphabetical ordering. This can lead to the following challenges:

• Performance degradation – Ad hoc queries land on large production warehouses, competing for resources with critical workloads
• Unpredictable costs – Large warehouses are started unnecessarily for lightweight, exploratory queries
• Governance challenges – Queries intended for exploration run on team-specific or application-specific warehouses.

Default Warehouse solves this directly.

The solution: Default Warehouse

Default Warehouse allows admins to set a single workspace-level default SQL warehouse for ad hoc SQL surfaces, including SQL Editor, Catalog Explorer, AI/BI Dashboards, Alerts, and Genie Spaces.

Users can customize their own Default Warehouse if needed (e.g., they are a power user with dedicated warehouses). Admins have visibility and ultimate control over the Default Warehouse users set.

This provides flexibility at both levels:

• Admins guide most ad hoc workloads to the intended warehouse.
• Most users don’t even have to think about selecting a warehouse, while power users can choose their own Default Warehouse that fits their workflows.

The result: ad hoc workloads run on the intended warehouse, saving costs for admins and saving time for users.

Impact validated by customers

More than 300 customers have already used Default Warehouse, and the value was clear and consistent:

• Effective at reducing costs for exploratory queries: Catalog Explorer queries going to smaller warehouses increased from 77% to 96% for workspaces where admins set the Default Warehouse to a smaller warehouse.
• Helpful in reducing the need for manual warehouse selection: The number of users running ad hoc SQL across multiple warehouses decreased by 15%. Users can now focus on analysis rather than compute selection.

Customers are already seeing real-world impact in production workloads.

By using the Default Warehouse setting, we have nearly eliminated improper use of our production dashboard SQL warehouse. Triaging performance issues is also much faster. —Michael Woffendin, Senior Engineering Manager, Rivian

Feature details

1. Workspace-level default for admins

Admins can configure a single default SQL warehouse in Workspace Settings → Compute.

• Applies across ad hoc SQL surfaces
• Supports serverless, pro, and classic SQL warehouses, respecting existing governance and access controls
• Opt-in (“Last Selected” when workspace-level default is not set)
• Automatically selected in new assets

2. User-level customization for flexibility

Users can configure an override for themselves in Warehouse Dropdown -> Customize your default warehouse:

• View the workspace default warehouse (“alp-sql-controltower” in the screenshot)
• Opt-out (follows workspace-level default, if override is not set)
• Override it to another warehouse, or choose “Last Selected” if preferred

3. Admin APIs for customization and governance

To enable admins to assign different warehouses to each user, we added APIs to view and set user-level defaults. This enables admins to:

• Programmatically set different warehouses per user based on the teams they belong to
• Audit which users have set user-level overrides
• Have the ultimate control over each user’s Default Warehouse selection

Example 1: Set Default Warehouse of all users in group “finance” to 

Example 2: Audit all users who have set their own Default Warehouse

For the full API reference, refer to the Databricks documentation.

This API is also available as a Terraform resource.

What’s next

We are extending Default Warehouse to support ad hoc workloads beyond the Databricks UI, including those from off-platform sources such as MLflow, Lakeflow CLI, and DBSQL MCP. 

Please let us know what you would like to see next to make your Databricks SQL management experience even better!

Try Default Warehouse today

To protect the performance of critical workloads and reduce surprise costs, use Default Warehouse to guide ad hoc queries to the right warehouse. Default Warehouse is generally available today.  To get started, see the Databricks documentation.