BI performance & cost control: Measure report path: source query, model calc, visual, shared capacity; Track recurring work: refreshes, deliveries, licences with usage and billing; Use diagnostics like Power BI Performance Analyzer and BigQuery jobs metadata
Image: Business Insight Stack

BI Architecture

BI system performance and cost control

Measure BI delays and recurring costs, locate the responsible workload, and check accuracy and freshness before accepting a change.

Manage BI performance and cost by measuring the reporting path, then changing the work behind avoidable delay or spend. A slow report may wait on a source query, model calculation, visual or shared capacity. Recurring queries, refreshes, deliveries and licences each need different cost checks.

Establish a baseline

Choose maintained reports that support recurring decisions. Record the reader, required data cutoff, busiest use period and acceptable wait. For each measurement, keep the report and model versions, connection mode, filters, data volume, cache state and concurrent work. Repeat the same page load and common interaction under comparable conditions.

Measure scheduled work as well as what the reader sees. Keep usage and billing records for the same observation period. Elapsed query time alone is not a bill: the charge depends on the service and the organisation's account terms.

Part of the pathUseful observationQuestion to ask
SourceQuery duration, work processed and concurrent jobsIs the report reading more than its decision needs?
ModelCalculation and refresh behaviourIs shared logic repeating expensive work?
ReportVisual and interaction timingWhich action delays the reader?
Scheduled workRuns, failures and overlapDoes each run serve a current output and required cutoff?
AccessAssigned licences and observed useDoes each paid entitlement still support a task?

Key Metrics to Monitor Across BI Operating Layers

Source Layer
Query duration, work processed, concurrent jobs
Model Layer
Calculation and refresh behaviour
Report Layer
Visual and interaction timing
Scheduled Work
Runs, failures, overlap
Access Layer
Licences assigned vs. observed use

Manage the whole operating path

Manage the operating path across data sources, the data model, visualisations and the environment, including capacities, data gateways and the network.

Place an observed constraint in its likely layer before choosing a response. This helps avoid changing a report when the limiting factor sits in shared capacity or connectivity, and gives the relevant owner a clearer decision to make.

A Power BI semantic model can support reports in Desktop and the browser, explorations, paginated reports, DAX queries, Excel reporting and exported visual data.

Locate the delay

Power BI's Performance Analyzer, available when editing a report, shows how long each visual takes to load and breaks load time down into categories, including the time taken by the DAX query. Use these timings as clues, then inspect the source, gateway or capacity where relevant.

BigQuery's INFORMATION_SCHEMA.JOBS view provides metadata about jobs in the current project. Snowflake Query History and Query Profile can help locate long-running work, subject to the user's access and the available history. Neither diagnostic view establishes a saving until the changed workload is measured.

Try a change aimed at the identified cause: a narrower query, simpler calculation, necessary visuals only, a different refresh time or a job with a confirmed lack of consumers. Check the figure, access and freshness after the change. A faster report with a changed population has missed its purpose.

Separate work from waiting

Distinguish time spent executing work from time spent waiting for shared resources. In Snowflake, Snowsight's Warehouse Activity chart shows warehouse load, including whether queries were queued; use queueing as a shared-workload signal when deciding whether the response belongs at report or environment level.

Historical task execution times can also help show whether scheduled transformations contribute to a busy period. Consider that evidence alongside reader-facing response and the agreed cutoff, so a change to recurring work does not improve one measure by undermining another.

Review recurring demand

Register interactive queries, refreshes, exports and scheduled deliveries with their owners and consumers. Frequency matters: modest work repeated many times can use substantial resources. Overlapping jobs may also cause a delay absent from a quiet test.

Compare each run with the agreed cutoff and delivery need. For licences, compare assignments with activity, then confirm unusual cases with the owner. An annual user or someone receiving a scheduled output may look inactive in a short usage window. Confirm purchase terms before reporting a monetary saving from an entitlement change.

Record the decision

Keep the baseline, proposed change, owner, expected effect and figures that must remain correct. Compare before and after using the same reporting population and representative workload where possible. State when a changed source, workload or contract limits the comparison.

Consider migration separately if the current arrangement cannot meet a defined requirement at an acceptable operating cost. Preserve metric definitions and reference results so a proposed replacement can be assessed for accuracy, access, freshness, performance and cost.

Assess the reach of a change

A change to a shared model can affect more than the maintained report used for the baseline. Check which other reporting and analysis uses depend on it, and include their required figures and freshness in the change decision.

Power BI semantic models can use Import, DirectQuery or Composite table storage modes. Record the relevant mode when describing the current arrangement, and treat choosing a different mode as a design decision to assess against the solution's requirements, not as an automatic performance or cost saving.

In this guide

  1. Diagnosing slow dashboards before replacing the toolReproduce a slow dashboard action, locate the delay, and test whether a targeted fix meets the reader’s need before considering replacement.
  2. Reducing expensive queries in recurring reportsFind repeated report queries, reduce unnecessary reads and runs, and verify the result under the relevant billing model.
  3. Monitoring unused BI licences and scheduled jobsCompare BI entitlements and scheduled jobs with actual tasks, telemetry coverage and dependencies before changing access or schedules.
  4. Planning a BI platform migration with reproducible metricsPlan a BI migration using versioned metric definitions, fixed reference data and explicit checks for accuracy, access, freshness and performance.

More from BI Architecture