Your finance team runs a critical month-end close report at 8:47 AM every Monday. Your sales leadership refreshes a pipeline dashboard every hour, pulling from a 200-million-row fact table. Your operations team runs twenty scheduled dataset refreshes between midnight and 6 AM. And somewhere, three different product managers are embedding Power BI reports into a customer-facing portal that just got mentioned in a press release. All of this is happening on the same Premium capacity — and you're watching the Capacity Metrics app light up like a pinball machine.
This is the actual problem with enterprise Power BI deployments: workloads are not uniform, they're not predictable in the naive sense, and they compete for the same pool of compute in ways that create cascading performance failures. Traditional approaches — throw more capacity at it, or just buy a bigger SKU — are expensive and still don't solve the architectural problem. What you need is a principled approach to capacity planning combined with intelligent autoscale configuration that keeps performance stable while controlling costs.
By the end of this lesson, you will be able to design a capacity architecture for enterprise workloads, configure Power BI Premium autoscale with proper safeguards, interpret the Capacity Metrics app at a diagnostic rather than descriptive level, and implement monitoring and alerting that catches resource pressure before users feel it.
What you'll learn:
This lesson assumes you are operating at an enterprise or near-enterprise scale. Before proceeding, you should have:
Before you can plan capacity intelligently, you need a mental model of what's happening inside the engine. Most capacity planning mistakes stem from treating Premium as a black box and trying to tune it from the outside. Let's fix that.
Power BI Premium capacity is measured in v-cores, and each SKU tier gives you a specific number. A P1 capacity gives you 8 v-cores, P2 gives 16, P3 gives 32, and so on. But these aren't simply CPU threads in the traditional sense — they map to the Analysis Services Tabular engine's concept of processing threads, and the engine divides them into distinct pools with different purposes.
The engine maintains separate thread pools for queries and for processing (dataset refresh). By default, query threads are capped at roughly 40% of available v-cores, and processing threads get the remainder, with some headroom reserved for system operations. This means on a P1 (8 v-cores), you effectively have around 3-4 dedicated query threads and 4-5 processing threads under normal conditions. Understanding this partition is critical because it explains why you can have slow query performance even when refresh operations are technically "done" — the thread pools don't immediately release and reassign.
Important: The thread allocation isn't a hard wall — the engine can borrow threads across pools under certain conditions. But during peak load, this borrowing causes queuing that shows up as the "Query wait duration" metric in the Metrics app. High query wait duration with low CPU utilization is almost always a threading bottleneck, not a raw compute problem.
Premium capacity memory is just as important as v-cores, and it behaves differently than you might expect. The Analysis Services engine maintains a memory resident model of each dataset. When a dataset is queried, it needs to be fully loaded into memory. When memory pressure occurs, the engine evicts datasets using a modified LRU (Least Recently Used) algorithm.
The dangerous scenario is dataset thrashing: when you have more datasets that need to be in memory simultaneously than your capacity has RAM, the engine constantly evicts and reloads datasets. Each reload triggers a cold read from storage, which is expensive. A P1 has 25 GB of memory, a P2 has 50 GB, a P3 has 100 GB. If your ten datasets average 4 GB each in memory (not on disk — the in-memory footprint is different from the file size), a P1 will thrash if more than six of them are actively queried simultaneously.
The Metrics app shows this through the "Dataset evictions" counter. If you're seeing consistent evictions during business hours, you have a memory sizing problem, not a compute problem — and buying more v-cores won't fix it.
Power BI applies a smoothing algorithm to capacity resource consumption. Rather than measuring instantaneous CPU spikes and throttling immediately, the system averages consumption over a 5-minute rolling window. This is both a blessing and a curse.
The blessing: short-lived operations that spike briefly don't immediately trigger throttling. A 10-second query that uses a lot of CPU won't cause the entire capacity to slow down.
The curse: if you have sustained load — like a 45-minute refresh job running concurrently with business-hour queries — the smoothed average climbs steadily. Once the smoothed average exceeds 100% of capacity, the system enters a throttle state called "overload," and interactive queries start getting queued. The Metrics app displays this as "Overloaded minutes."
Understanding the smoothing window is essential for autoscale threshold design, which we'll cover in detail shortly.
Guessing at SKU size is expensive. Either you overprovision and pay for capacity you're not using, or you underprovision and your users suffer. The right approach is a structured sizing exercise using actual workload data.
Open the Power BI Premium Capacity Metrics app and navigate to the system summary view. You want at least 30 days of data — ideally 60 — so you capture both typical weeks and atypical peaks (month-end, quarter-end, major releases).
From the app, extract the following metrics for each day:
Do not use averages for everything. Averages lie at scale. A day where CPU averages 40% but peaks at 180% for 45 minutes is not the same as a day where CPU runs steadily at 40%. Your users only feel the peaks.
Workloads in enterprise environments follow predictable patterns, but the patterns vary significantly by organization. Map your extracted metrics to the following workload archetypes:
Bursty Interactive: Heavy query load during business hours (8 AM – 6 PM), light or no load overnight. Common in sales, marketing, and executive dashboards. The resource signature is high CPU and memory during the day, with regular daily peaks around 9-10 AM and 2-3 PM.
Batch Heavy: Significant refresh operations running overnight or during off-peak hours. Common in finance and operations. The resource signature is high CPU and memory from midnight to 6 AM, relatively quiet during the day. These organizations often have the opposite of what you'd expect — a bigger capacity than they need for interactive queries, because they sized for batch throughput.
Mixed Concurrent: Both heavy refreshes and active queries happening simultaneously. This is the hardest workload to plan for and the most common in mature enterprise deployments. The resource signature is elevated CPU and memory almost all the time, with extreme spikes when batch and interactive load coincide.
Embedded/Customer-Facing: Unpredictable concurrency spikes tied to external events (marketing campaigns, product launches, end-of-period customer reporting). The resource signature is highly irregular and correlated with business events rather than time of day.
Once you know your workload pattern, calculate your sizing target using this framework:
Take your 90th percentile peak CPU from the past 30 days. Multiply by 1.25 to add a 25% headroom buffer. That's your target sustained compute level. Then find the SKU whose v-core count supports that level. If you're autoscaling, your base SKU should handle your typical weekday load, and autoscale covers your peaks.
For memory, the calculation is simpler: sum the in-memory sizes of all datasets that could plausibly be queried simultaneously during peak hours. Add 15% overhead for engine operations. That's your minimum memory requirement.
Pro tip: The Metrics app shows dataset sizes in GB, but these are on-disk sizes. The in-memory footprint after decompression is typically 3x to 10x the compressed on-disk size, depending on data cardinality and model complexity. A 2 GB PBIX file might expand to 8-15 GB in memory. Always measure actual memory consumption from the Metrics app rather than estimating from file size.
Large enterprises rarely benefit from a single monolithic capacity. Consider partitioning workloads across multiple capacities based on criticality, concurrency, and refresh patterns:
Tier 1 – Business Critical: Executive dashboards, regulatory reports, customer-facing embeds. Size this capacity conservatively (lower utilization target) and enable autoscale. Prioritize interactive query performance. Assign only production, validated datasets here.
Tier 2 – Operational Workloads: Standard department reporting, high-volume scheduled refreshes, analyst workspaces. This is your workhorse capacity. Tune for throughput over latency.
Tier 3 – Development/Test: Developer workspaces, prototype models, exploratory analysis. Use the smallest viable SKU. Do not put Dev/Test on the same capacity as production — a runaway query in a developer's test model will affect production users on the same capacity.
This multi-capacity architecture does increase administrative overhead, but the performance and cost isolation benefits are substantial. Importantly, you can apply different autoscale configurations to each capacity tier.
Autoscale for Power BI Premium allows the platform to automatically provision additional compute capacity when your base SKU is under pressure, and release it when the pressure subsides. It's billed per v-core per hour, and it can represent significant additional cost if misconfigured. Let's get into the mechanics.
Autoscale operates through Azure, specifically through Azure Analysis Services' scale-out mechanism applied to the Power BI backend. To enable it, you need:
The autoscale relationship between Power BI and Azure is direct billing linkage. When additional v-cores are provisioned, the cost appears on your Azure bill, not your Power BI subscription. This matters for enterprise cost management because it means you need to align Finance, IT, and Azure billing contacts before enabling autoscale, or you'll get unpleasant surprises at month-end.
To link an Azure subscription to your Power BI capacity for autoscale:
Navigate to the Power BI Admin Portal (app.powerbi.com, then the gear icon, then Admin Portal). Select "Capacity settings" from the left navigation, then choose the capacity you want to configure. In the capacity settings panel, locate the "Autoscale" section. You'll see an option to connect an Azure subscription. Click it and follow the authentication flow to select the appropriate Azure subscription and resource group.
The resource group you select becomes the billing scope for autoscale charges. Create a dedicated resource group for Power BI autoscale costs if your organization uses resource-group-level cost tracking — this makes chargeback and showback dramatically simpler.
Warning: Once you link a subscription and autoscale triggers, there is a minimum billing increment of one v-core-hour, rounded up. If autoscale provisions an extra 2 v-cores for 15 minutes, you're billed for 2 v-core-hours. At P1 v-core prices, this adds up faster than you'd expect during sustained load periods.
The most critical and most often misconfigured aspect of autoscale is the threshold settings. Power BI autoscale lets you set:
Let's reason through threshold design carefully, because this is where most enterprise implementations go wrong.
The autoscale trigger evaluates capacity utilization over the same 5-minute smoothing window discussed earlier. If the smoothed average exceeds your threshold, autoscale provisions additional v-cores. Provisioning is not instantaneous — it takes approximately 2-5 minutes to provision and stabilize the new compute. This means your users will experience throttling during that provisioning window.
The implications are significant: if you set your autoscale trigger threshold at 100% (the maximum), autoscale only fires when you're already in an overloaded state. By the time additional compute is available, your users have already waited. You want to trigger autoscale before you hit 100%.
A well-designed threshold strategy looks like this:
This is the conversation your organization needs to have, and it requires numbers.
Power BI Premium P-SKU pricing (at the time of writing) runs approximately $4,995/month for P1, $9,995 for P2, and $19,995 for P3. These are fixed costs.
Autoscale v-cores are billed at approximately $0.47 per v-core per hour (this varies by Azure region and changes over time — always check current Azure pricing). If you're on P1 and autoscale provisions 8 additional v-cores for 2 hours every business day, that's:
8 v-cores × 2 hours × 22 business days = 352 v-core-hours/month
352 × $0.47 = ~$165/month in autoscale charges
That's extremely reasonable. But if autoscale is provisioning during a much longer window, the math changes:
8 v-cores × 8 hours × 22 business days = 1,408 v-core-hours/month
1,408 × $0.47 = ~$662/month in autoscale charges
At $662/month in sustained autoscale charges, you're approaching the point where a permanent upgrade to P2 makes financial sense. The crossover point is when monthly autoscale charges exceed the price differential between SKU tiers. Run this calculation with your actual consumption data before committing to an autoscale-heavy architecture.
Architecture rule of thumb: Autoscale is economically justified for workloads that spike to 2x your base capacity for less than 30% of business hours. If your workload regularly exceeds base capacity for more than 30% of the time, upgrade your SKU.
The Capacity Metrics app is excellent for historical analysis, but it is not a real-time monitoring tool. Building a proactive monitoring system means getting metrics out of Power BI and into an alerting pipeline before your users start filing support tickets.
Power BI exposes capacity metrics through the Admin REST API. The key endpoints for capacity monitoring are:
GET https://api.powerbi.com/v1.0/myorg/admin/capacities
GET https://api.powerbi.com/v1.0/myorg/admin/capacities/{capacityId}/workloads
These return current workload configurations but not real-time utilization — that requires a different approach. For real-time and near-real-time metrics, you have two viable paths.
Path 1: Power BI Capacity Metrics Dataset via XMLA
The Capacity Metrics app installs a dataset in your workspace that the app reads from. This dataset is queryable via the XMLA endpoint if you have Power BI Premium. You can connect to it from SSMS (SQL Server Management Studio), Azure Data Studio, or any XMLA-compatible client using the workspace connection string:
powerbi://api.powerbi.com/v1.0/myorg/[YourWorkspaceName]
Once connected, you can run DAX queries against the Capacity Metrics dataset directly. Here's a useful monitoring query that extracts the key metrics for the past 24 hours:
EVALUATE
CALCULATETABLE(
SUMMARIZECOLUMNS(
'Capacity'[CapacityName],
'TimePoint'[TimePoint],
"CPU_Percent", [CPU %],
"Memory_GB", [Memory (GB)],
"QueryWait_ms", [Query Wait Duration (ms)],
"Evictions", [Dataset Evictions Count],
"OverloadedMinutes", [Overloaded Minutes]
),
DATESINPERIOD(
'TimePoint'[TimePoint],
NOW(),
-1,
DAY
)
)
ORDER BY 'TimePoint'[TimePoint] DESC
Note: The exact measure names in the Capacity Metrics dataset vary by version. Always verify measure names after app updates by browsing the model in SSMS before building monitoring queries.
Path 2: Azure Monitor Integration
For organizations already using Azure Monitor, Log Analytics, or Azure Sentinel, Power BI can emit diagnostic logs that flow into your existing observability infrastructure. Enable diagnostic settings on your Power BI Premium capacity by navigating to the Azure portal, finding your capacity resource (it appears as an Azure resource once you've linked your subscription for autoscale), and configuring diagnostic settings to route to a Log Analytics workspace.
Once configured, capacity metrics flow into the AzureDiagnostics table in Log Analytics. You can query them using KQL:
AzureDiagnostics
| where ResourceType == "CAPACITIES"
| where TimeGenerated > ago(24h)
| project TimeGenerated,
CapacityName = Resource,
CPU_Percent = todouble(cpu_d),
Memory_GB = todouble(memory_d),
QueryWaitDuration_ms = todouble(queryWaitDuration_d)
| where CPU_Percent > 70
| order by TimeGenerated desc
From Log Analytics, you can build Azure Monitor alert rules that fire when CPU exceeds a threshold, when overloaded minutes accumulate beyond a tolerance, or when eviction counts spike unexpectedly. Route these alerts to Azure Action Groups that notify your capacity administrators via email, Teams, or PagerDuty depending on severity.
Alert fatigue is real, and a monitoring system that fires too often gets ignored. Design your alert thresholds in layers:
Layer 1 – Informational (no page, log only)
Layer 2 – Warning (Teams notification to admin channel)
Layer 3 – Critical (email + Teams to admin and manager)
The third layer is your escalation trigger — it means your capacity architecture is insufficient for the current load, and either something has gone wrong (a runaway refresh, an unexpectedly large data load) or you need a permanent architecture change.
Resource allocation without workload isolation is like traffic engineering without lane designations. You end up with every vehicle competing for every lane, and the whole system degrades under load.
In the Capacity settings section of the Admin Portal, you can configure resource limits for specific workload types within a capacity. The workloads you can tune include:
For a typical enterprise capacity with a mix of interactive reports and scheduled refreshes, configure workload settings as follows:
For the Datasets workload, set maximum memory to 75% if you have other workloads competing. Enable large model storage only if you have models that exceed the standard size limits — large model storage changes how the engine handles memory pressure and introduces some overhead. Enable query parallelism if you have many short interactive queries, but be cautious — aggressive parallelism can starve refresh operations of threads.
For Paginated Reports, allocate no more than 20% of capacity memory. Paginated reports tend to be heavy on memory during rendering but bursty rather than sustained. Constraining their memory pool prevents a large paginated report from evicting your interactive datasets.
The most underutilized capacity management technique in Power BI is deliberate refresh scheduling. Most enterprise environments I've seen have refresh schedules that were set up when the datasets were first created and never revisited. The result is all refreshes clustered at the hour boundary (midnight, 2 AM, 4 AM) because that's the default.
Stagger your refresh schedules deliberately to smooth the load profile. If you have 20 datasets that refresh at midnight, spread them across the 11 PM to 4 AM window in 15-minute increments. The aggregate CPU and memory load will be nearly identical, but the peak will be dramatically lower because you're not forcing the engine to start 20 simultaneous refresh operations.
For datasets that refresh multiple times per day, think carefully about whether every refresh is genuinely necessary. A dataset refreshing every 30 minutes but queried only once per hour is consuming twice as many refresh resources as needed. If you're using DirectQuery for the frequent-change tables and Import for the slower-changing dimensions (a hybrid model approach), you can often reduce full refresh frequency significantly.
Power BI Premium queues refresh operations when all processing threads are occupied. By default, the queue is essentially first-in-first-out. You can influence prioritization by using the Power BI REST API to trigger refreshes programmatically rather than relying on the scheduled refresh engine.
The key API endpoint for programmatic refresh:
POST https://api.powerbi.com/v1.0/myorg/groups/{groupId}/datasets/{datasetId}/refreshes
With a request body like:
{
"notifyOption": "MailOnFailure",
"retryCount": 2,
"type": "full",
"commitMode": "transactional"
}
By orchestrating refreshes through Azure Data Factory, Azure Logic Apps, or a custom Python script using the Power BI REST API client library, you can implement dependency-aware refresh sequencing. Refresh the fact tables after the dimension tables complete, refresh Tier 1 datasets before Tier 2, and hold off on non-critical refreshes during known peak query periods.
Here's the Python pattern for a dependency-aware refresh using the official Power BI client library:
from azure.identity import ClientSecretCredential
import requests
import time
def refresh_dataset(group_id: str, dataset_id: str, token: str) -> str:
"""Trigger a dataset refresh and return the operation ID."""
url = f"https://api.powerbi.com/v1.0/myorg/groups/{group_id}/datasets/{dataset_id}/refreshes"
headers = {
"Authorization": f"Bearer {token}",
"Content-Type": "application/json"
}
payload = {
"notifyOption": "MailOnFailure",
"type": "full",
"commitMode": "transactional"
}
response = requests.post(url, headers=headers, json=payload)
response.raise_for_status()
# The operation ID is in the Location header
return response.headers.get("RequestId")
def wait_for_refresh_completion(
group_id: str,
dataset_id: str,
token: str,
poll_interval_seconds: int = 30,
timeout_minutes: int = 120
) -> bool:
"""Poll refresh status until completion or timeout."""
url = f"https://api.powerbi.com/v1.0/myorg/groups/{group_id}/datasets/{dataset_id}/refreshes"
headers = {"Authorization": f"Bearer {token}"}
elapsed = 0
max_seconds = timeout_minutes * 60
while elapsed < max_seconds:
response = requests.get(url, headers=headers)
response.raise_for_status()
refreshes = response.json().get("value", [])
if not refreshes:
return False
latest = refreshes[0] # API returns most recent first
status = latest.get("status")
if status == "Completed":
return True
elif status in ["Failed", "Disabled"]:
raise RuntimeError(
f"Refresh failed. Status: {status}. "
f"Error: {latest.get('serviceExceptionJson', 'Unknown error')}"
)
time.sleep(poll_interval_seconds)
elapsed += poll_interval_seconds
raise TimeoutError(f"Refresh did not complete within {timeout_minutes} minutes")
# Example: Chain refreshes with dependency awareness
def run_orchestrated_refresh(credential, workspace_configs: list[dict]):
"""
workspace_configs is a list of dicts with group_id and dataset_id,
ordered by dependency (index 0 refreshes first).
"""
token = credential.get_token("https://analysis.windows.net/powerbi/api/.default").token
for config in workspace_configs:
print(f"Starting refresh for dataset: {config['name']}")
refresh_dataset(config["group_id"], config["dataset_id"], token)
success = wait_for_refresh_completion(
config["group_id"],
config["dataset_id"],
token
)
if success:
print(f"Completed: {config['name']}")
else:
raise RuntimeError(f"Refresh failed for {config['name']}. Stopping chain.")
This pattern, wrapped in an Azure Function or ADF pipeline, gives you full control over refresh sequencing and prevents the capacity from being overwhelmed by concurrent batch operations.
In this exercise, you'll conduct a capacity health assessment, configure autoscale, and build a basic monitoring alert. This assumes you have access to a Premium capacity and the Capacity Metrics app is installed.
You're the data platform engineer for Meridian Logistics, a mid-size freight and supply chain company. Your Power BI environment has:
You've been getting complaints that Monday morning reports are slow between 8:30 and 10:30 AM.
Open the Capacity Metrics app and filter to the past four Mondays. Navigate to the System Summary tab and look at the hourly CPU and Memory charts.
What to look for:
Document your findings: Write down the peak CPU percentage, the number of evictions per hour, and the top 3 datasets by query wait duration. These three numbers tell you whether you have a CPU problem, a memory problem, or a specific model optimization problem.
Based on your analysis, you've found that two large overnight refreshes are still running at 8:30 AM on Mondays because they take longer than expected. They're completing around 9:15 AM, right when users start working.
In the Power BI service, go to each dataset's settings and navigate to Scheduled Refresh. Shift the Monday refresh time from its current 6:00 AM start to 3:00 AM. This gives the refreshes a 5-hour window to complete before business hours.
Additionally, identify any refreshes currently scheduled on the hour boundary (midnight, 2 AM, 4 AM) and offset them by 15 minutes to prevent simultaneous starts.
In the Power BI Admin Portal, navigate to Capacity settings for your P1 capacity. Locate the Autoscale section.
Configuration targets:
After saving, document the Azure resource group where autoscale charges will appear. Send that resource group name to your Finance team so they can set up a budget alert in Azure Cost Management. Set the budget alert at 120% of your expected monthly autoscale spend.
In SSMS, connect to your workspace via the XMLA endpoint. Open a new DAX query window against the Capacity Metrics dataset. Run the following query to identify your capacity's worst hours over the past 30 days:
EVALUATE
TOPN(
20,
SUMMARIZECOLUMNS(
'TimePoint'[Date],
'TimePoint'[Hour],
'Capacity'[CapacityName],
"Peak_CPU", MAXX(RELATEDTABLE('Utilization'), [CPU %]),
"Eviction_Count", SUMX(RELATEDTABLE('Utilization'), [Dataset Evictions Count]),
"Avg_Query_Wait", AVERAGEX(RELATEDTABLE('Utilization'), [Query Wait Duration (ms)])
),
[Peak_CPU],
DESC
)
Export the results to Excel and create a pivot chart showing CPU peaks by day of week and hour. This becomes your capacity baseline document. Review it monthly.
The most common and most expensive mistake. You calculate that average CPU utilization is 45%, conclude you have plenty of headroom, and then get throttled every Monday at 9 AM. Average utilization is only meaningful if your load is perfectly uniform, which it never is. Always size for your 90th percentile peak.
Autoscale without a maximum v-core limit can generate unconstrained Azure spend. Always set a maximum autoscale v-core count. Always create an Azure budget alert at 150% of your expected autoscale spend. Without these guardrails, a single misconfigured refresh job that runs for 12 hours can generate hundreds of dollars in unexpected autoscale charges.
When memory pressure occurs and the engine must evict datasets, it doesn't know which datasets are business-critical and which are experimental. If a developer's test dataset with a huge in-memory footprint gets queried right before a C-suite dashboard, the C-suite dashboard might get evicted. The solution is workspace separation across capacity tiers, as discussed in the architecture section. Don't compromise on this — keeping development and production on the same capacity is a reliability risk, not just a performance nuisance.
If you set your autoscale trigger at 95% utilization, autoscale won't save your users because the additional compute won't be available for 2-5 minutes after trigger. During that provisioning window, your capacity is already throttling. Lower your trigger threshold to 70-75% and accept the higher autoscale frequency. The cost difference is minor compared to the SLA breach you'd get from users experiencing slow reports.
This is the "throw hardware at it" anti-pattern. Before spending more on capacity, audit your models. Common model-level issues that masquerade as capacity problems:
A well-optimized model can outperform a poorly-optimized one by 5-10x on the same hardware. Always optimize models before upgrading capacity.
If autoscale is configured but not triggering during high-load periods, check:
Microsoft.PowerBIDedicated resource provider must be registered in your Azure subscription. Check this in the Azure portal under Subscriptions > Resource Providers.If you're seeing dataset evictions overnight during refresh operations, it's typically because refresh operations load models into memory (alongside the incoming data) and the combined footprint exceeds available RAM. Solutions:
Capacity planning for Power BI Premium is not a one-time exercise — it's an ongoing operational discipline. The organizations that handle it best treat it like infrastructure capacity planning: they have baseline metrics, they review trends monthly, they have alerts that fire before users feel problems, and they revisit their architecture when workloads change.
Let's summarize the key principles from this lesson:
Model the engine, not just the metrics. Understanding the threading model, memory eviction behavior, and smoothing algorithm lets you diagnose problems correctly instead of just throwing more capacity at them. High query wait duration with moderate CPU is a threading problem. Evictions during business hours are a memory sizing problem. Sustained CPU above 80% is a true compute problem.
Size for peaks, not averages. Your 90th percentile peak determines your capacity requirement. Build in 25% headroom above that, and use autoscale to cover the remaining variance economically.
Autoscale is a cost-efficiency tool, not a performance tool. Autoscale compensates for unpredictable spikes in a way that's cheaper than permanent over-provisioning. But it has provisioning lag, and it becomes expensive if your peaks are sustained rather than transient. Use the crossover calculation to determine when a SKU upgrade beats continued autoscale charges.
Isolate workloads across capacity tiers. Production, development, and embedded customer-facing workloads have different reliability requirements and different resource profiles. Mixing them on a single capacity is a reliability risk.
Build proactive monitoring, not reactive dashboards. The Capacity Metrics app is great for forensics. Azure Monitor alert rules and XMLA-based monitoring queries are what keep you ahead of problems.
With this foundation in place, your logical next areas of depth are:
The goal is an enterprise Power BI environment that's predictable, observable, and cost-efficient — one where performance problems are caught by monitoring, not by users.
Learning Path: Enterprise Power BI