SQL databases in Fabric run as interactive rather than background workloads

[Nagesh_Rao]

One major challenge I've run into with SQL databases in Fabric is that they run as interactive rather than background workloads. Because the database has to stay online, it continuously consumes CUs, which puts real pressure on shared capacity where pipelines, notebooks, and Power BI are competing for the same resources.

Today the only isolation option is moving the SQL database into its own workspace on a dedicated capacity, which adds management overhead and cross-workspace friction. It would be great to see item-level capacity assignment or workload isolation for SQL databases within a capacity — or a background/idle classification so an always-on database isn't billed like an active interactive workload.

Is anything like this on the roadmap?

[ShivekMaharaj]

Hi @Nagesh_Rao,

I think there are two separate things here: the interactive classification of SQL Database usage, and whether an idle database continuously consumes capacity.

On the second point, there has been an important change/improvement. A Fabric SQL Database does not need to consume compute indefinitely just because the item exists. Microsoft now documents that it scales compute down to zero after 15 minutes of inactivity. Storage continues to be charged, but compute does not.

Microsoft explains the behaviour under Billing and utilization reporting for SQL Database in Fabric.

The interactive classification point is still relevant, though. In the current Fabric operations table, SQL Usage for a SQL Database is classified as Interactive, whereas Warehouse Query usage is classified as Background. That means they participate differently in Fabric's smoothing/throttling model.

There is also now a useful middle ground before isolating the database onto another capacity: Microsoft has introduced a per-database max vCore setting in preview.

Under the database settings you can currently cap an individual SQL Database at 2, 4 or 32 vCores. The documentation specifically calls this out as a way to limit peak CU consumption in a shared capacity and reduce the chance of one database creating unexpected pressure: Control compute usage for SQL Database in Fabric.

So if my concern was a SQL Database competing with notebooks, pipelines and Power BI on the same capacity, I would probably try a suitable max-vCore guardrail first and then monitor the database in the Capacity Metrics app before moving it to a separate capacity.

I checked the current Fabric roadmap as well. I don't currently see a published SQL Database item for per-item capacity assignment or for changing SQL Database compute from interactive to background, so I wouldn't assume either is committed yet.

I do think the broader isolation requirement is a reasonable one, especially where several operational databases share capacity with latency-sensitive analytical workloads. The new vCore limit gets part of the way there, but it isn't the same thing as a true per-item capacity boundary.

I hope that helps clarify the current behaviour.