SKU Selection: Use Workload Evidence and Explicit Constraints
Compare adjacent capacities with the same workload, licensing needs, and acceptance checks.
Справочная статья на английском
Write the constraints first
Record the reporting and engineering tasks, their schedule, tolerated delay, data freshness target, user-license model, and expected growth. Distinguish a tested requirement from an assumption. A tier name does not establish a fixed user count, a universal memory guarantee, or the performance of your next query.
Compare two candidates
For an illustrative F32-versus-F64 decision, separate the compute comparison from organizational Power BI viewing rights. F64 or higher is relevant when qualifying free-license viewers consume appropriately assigned Power BI content. Copilot eligibility is a different question: paid F2 or higher may qualify, subject to region, tenant settings, and feature conditions. Do not upgrade solely because an old guide says Copilot universally requires F64.
Run the same acceptance cases
Test the representative refresh, a busy report period, concurrent background work, a source failure, and recovery after interruption. Keep the same source snapshot and report version for the comparison. Record operation consumption, rejected work, correctness, and user-visible response times. A short utilization spike alone does not establish that the next tier is necessary or sufficient.
Document the decision
Explain which observed constraint the proposed tier addresses and which uncertainty remains. Check current regional compute prices, storage, licenses, and reservation terms separately. Establish a review date and a rollback or rescheduling plan. A small pilot may show that a query change solves the issue; another workload may need more headroom. Treat the site's calculator as a way to organize assumptions, then validate the selected tier against real workload evidence before making a production commitment.