SQL databases in Fabric run as interactive rather than background workloads

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.

AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.