(+351) 21 24 10006  ·  info@bconcepts.pt
Carnaxide, Lisbon

DP-600: optimize measures with Aggregations and Storage Modes

João Barros 02 de September de 2026 6 min read

I will teach you the skill of optimizing measures using Aggregations and Storage Modes in semantic models (Power BI/Fabric). This is a practical ability valued in the DP-600 exam and, above all, in operating analytics solutions with large data volumes where performance and cost matter. The core idea is to reduce work by the query engine through pre-calculations and storage choices that balance memory, latency and source load.

What you need to know

Aggregations are pre-computed tables or calculations that summarize detailed data. For example, instead of summing five million sales rows in real time to get the monthly total, you create an aggregated table with TotalSales by month. Storage Modes determine how tables are accessed and stored in the model: Import (data loaded into the model and kept in memory), DirectQuery (all queries hit the source in real time) and Dual (a hybrid behavior that allows a table to be used as Import or DirectQuery depending on the context).

Concrete example: you have a Sales table with 120 million rows covering 5 years, and a Calendar table with 1,825 days. Instead of always querying the detailed Sales for monthly reports, you create an aggregated Sales_Monthly table with 60 months × 10 regions = 600 rows (or 60 × 500 products = 30,000 rows if you aggregate by product). In practice this can reduce the data volume to read by 99% for aggregated queries, bringing response times from 6–8 seconds down to the order of hundreds of milliseconds.

How it works in practice

Main steps to implement optimizations with Aggregations and Storage Modes:

  1. Identify query patterns: analyze reports and telemetry logs (Query Diagnostics, Performance Analyzer) to know which dimensions and detail levels are most used (e.g.: month, region, product). If 80% of queries request data by month and region, focus on that aggregation.
  2. Create aggregated tables: summarize the detail table for the most queried levels. For example, YEAR, MONTH, REGION → SUM(SalesAmount) and COUNTROWS for volumes. If the detail table has 120M rows, the aggregation may have a few hundred or thousand rows depending on the granularity level.
  3. Set appropriate Storage Modes: typically, aggregated tables are kept in Import for fast response; the detail table can be in Import or DirectQuery depending on volume and acceptable latency. For example, you keep the aggregation in Import (2 GB) and the detail in DirectQuery to avoid loading 120 GB of data into the model.
  4. Configure relationships and hierarchies: ensure keys and relationships allow the model engine to automatically substitute queries to use the aggregations. Keep key columns consistent (e.g.: Year, MonthNumber, RegionID) and time hierarchies in Calendar so the engine can do the mapping.
  5. Validate aggregation coverage: ensure aggregations cover the frequent filter combinations; when they don’t, the engine will fall back to the detail table and the query will be slower. Create tests that simulate 90–95% of user scenarios before promoting the aggregation to production.

Practical example (DAX / conceptual steps):

// 1. Create an aggregated table in Power BI Desktop (if you already have the Sales table in Import)
Sales_Monthly =
SUMMARIZE(
  Sales,
  Calendar[Year],
  Calendar[MonthNumber],
  "TotalSales", SUM(Sales[SalesAmount])
)

// 2. Mark Sales_Monthly as an aggregation table and set key columns (in the model) — this is done through the Power BI/Fabric interface.

After creating the table, use Performance Analyzer to compare render times: for example, a chart that previously took 7s may go to 250–400ms when the engine uses the appropriate aggregation.

Notes about Storage Modes:

  • Import: fast, depends on memory and storage (OneLake when using Fabric). Good for aggregations and data that does not change frequently. Example: importing 30,000 rows takes a few MB and enables instant responses.
  • DirectQuery: queries the source live. Ideal for highly volatile data or very large data that cannot fit in Import. It typically has latencies from hundreds of ms to seconds, and impacts source performance.
  • Dual: allows the same table to behave as Import or DirectQuery depending on the query context — useful for small dimension tables (e.g.: Product or Region) that are used both as filters and in joins with tables in DirectQuery.

Common mistakes

1) Assuming a single aggregation covers all scenarios: different reports may use different dimensions. If you only create an aggregation by month/region and users also filter by product, the engine will fall back to the detail table, negating expected gains. Analyze patterns before designing aggregations.

2) Storing too many aggregations in Import without controlling refresh and size: each aggregation is imported and increases memory and refresh time. If you have 20 aggregations totaling 10 GB, full refreshes can take hours. Use incremental refresh and prioritize aggregations with the highest ROI.

3) Using DirectQuery indiscriminately: while it avoids importing data, DirectQuery can cause high latencies and heavy load on the source. A good hybrid strategy is to keep aggregations in Import for common scenarios and DirectQuery for drill-through or real-time reporting.

How to practice

Practice these steps in a controlled environment: create a report with a large Sales table (simulate 50–120M rows with generated data) and a Calendar. Implement monthly and region aggregations and compare response times for visuals with and without aggregations. Test different Storage Modes (for example, Sales detail in DirectQuery and aggregations in Import) and observe fallback behavior and resource usage. Measure memory, refresh time and report latency.

For alignment with the DP-600 exam, consult the official Practice Assessment and the Microsoft study guide — they are recommended official resources for practice and verifying the skills measured. Also use Performance Analyzer and Query Diagnostics documentation to validate real gains.

In summary

  • Aggregations summarize data to improve performance for aggregated queries; volume reductions of 90–99% are common.
  • Storage Modes (Import, DirectQuery, Dual) determine where and how data is accessed; choosing correctly balances performance, cost and source load.
  • Analyze query patterns before creating aggregations; avoid oversizing and insufficient coverage and implement incremental refresh when needed.
  • Practice in real environments, measure before/after and use Microsoft’s official resources (Practice Assessment and study guide) to prepare for the exam and validate your skills.