Compute auto-scaling choices to better optimize price-performance for SQL databases in Microsoft Fabric (Preview)

[Amar_Patil]

One of the most common pieces of feedback we hear from customers using SQL databases in Microsoft Fabric is the need for stronger cost control and predictable resource usage, especially in shared capacities.

Today, SQL databases in Fabric automatically scale to meet workload demand. This delivers great performance, but in shared environments it can also mean that a single database temporarily consumes a large share of capacity.

To address this, a new Compute setting for SQL database in Microsoft Fabric gives users an explicit way to cap the maximum compute a database can consume, without changing existing behavior by default.

What’s new

SQL databases in Fabric now expose a Compute configuration in database settings.

This setting defines the upper vCore limit the database can reach when scaling.

• By default, databases continue to behave exactly as they do now.
• Administrators can optionally cap a database at a lower maximum for cost control.
• The setting applies at the database level and works within the existing Fabric capacity model.

This change is designed to be opt‑in, safe by default, and fully backward compatible.

Default behavior stays the same

When this feature becomes available:

• Existing databases are unchanged.
• New databases default to the current behavior.
• The default maximum remains 32 vCores, aligned with today’s Fabric SQL experience.

If you do nothing, your databases will continue to scale and perform exactly as they do today.

New compute options

In the Compute section of SQL database settings, you will now see a Max vCores limit option.

You can choose:

• 32 max vCore (default) - by default, the database can scale-up to a maximum of 32 vCores, matching today's behavior.
• 4 vCores - Caps the database at a lower maximum for predictable cost and reduced capacity impact.

This gives you a simple, clear way to trade peak performance for cost predictability when appropriate.

Compute_auto-scaling_choices_to_better_optimize_price-performance_for_SQL_databa

" />

Figure: SQL database Compute preview settings showing a configurable Max vCores limit, with 32 vCores selected as the default.

Compute_auto-scaling_choices_to_better_optimize_price-performance_for_SQL_databa

" />

Figure: SQL database Compute preview showing the Max vCores limit dropdown open with 32 vCores selected.

Compute_auto-scaling_choices_to_better_optimize_price-performance_for_SQL_databa

" />

Figure: SQL database Compute preview with the Max vCores limit changed to 4 vCores.

Why it matters

Better cost control

By configuring max vCores, you define an upper bound on the maximum compute (vCores and memory) that a database can consume. This makes it easier to control costs and plan and managed Fabric capacity.

Some databases like dev/test databases and lighter weight production workloads do not need bursting headroom up to 32 max vCores to satisfy application performance requirements. In those cases, costs can be potentially reduced by explicitly limiting the auto-scaling range up to 4 max vCores instead of the 32 max vCoresdefault

Protection from noisy neighbors

In shared Fabric capacities, one busy database can temporarily dominate resources. Compute limits act as a guardrail so that no single database can overwhelm the rest of the workspace.

How it works at runtime

• The database continues to automatically scale based on workload demand.
• When usage approaches the configured max vCores limit, scaling stops at that cap.
• Workloads continue to run but may take longer to complete once the limit is reached.
• There is no interruption to availability during normal operation.

This means the database degrades gracefully under load rather than failing.

What happens when you change the setting

Changing the max vCores limit is a configuration update and may involve a brief transition while the database applies the new setting.

During this update:

• You may see a short connectivity interruption.
• Existing data is preserved.
• The database resumes with the new compute limit in effect.

If a downscale is requested that is incompatible with the current database size, the update will fail with a clear error message so you can take action.

Designed for Fabric—familiar to SQL users

This experience aligns closely with how customers already manage cost and performance in Azure SQL, while remaining fully integrated into the Fabric capacity model.

• This includes simple controls
• Safe defaults
• Clear trade‑offs
• No change unless you opt in

Getting started

You can find the Compute (Preview) option in the SQL database settings pane in Microsoft Fabric.

No action is required unless you want to apply limits.

Summary

Capabilities with the new Compute settings for SQL databases in Microsoft Fabric:

• Keep today’s behavior by default.
• Configure the max vCores cap as needed.
• Control costs better and improve capacity governance.
• Protect shared environments from resource contention.

This is an important step toward giving customers fine-grained control without sacrificing simplicity, and it lays the foundation for richer scaling and governance capabilities in the future. The default experience remains unchanged, ensuring continuity for existing workloads.

Learn more about current limits and edge cases in the documentation, which will be updated as this capability continues to evolve.