Forum Discussion
Unexpected multiple Athena query executions in Power BI
We are observing unexpected multiple Amazon Athena query executions in Power BI:
Although the dataset refresh is scheduled at 10:00 AM, Athena queries start executing as early as 6:00 AM, and at 10:00 AM multiple executions occur, each scanning the full dataset.
As part of our investigation, we used the native Amazon Athena connector (DirectQuery mode) and also disabled background analysis by turning off the “Allow data preview to download in the background” option in Power BI Desktop, which is commonly recommended to reduce unnecessary executions. Despite this setup, the behavior persists.
Any insights from the community would be appreciated.
The unexpected Athena activity is likely driven by Power BI's metadata maintenance and its multi-query engine.
Why it’s happening
• The 6:00 AM Gap: This is usually Dashboard Tile Refreshes or Cache Updates. Even if a scheduled refresh is at 10:00 AM, pinned dashboard tiles or "Automatic Page Refresh" settings trigger independent queries to check for schema or data changes.
• Multiple 10:00 AM Scans: * Visual Parallelism: Power BI executes a separate query for every visual on a page. Five charts = five Athena scans.
• Privacy Levels: If Data Privacy levels are set to "Organizational" or "Private," the engine often runs redundant queries to prevent data leakage between sources.
Quick Fixes
• Consolidate Privacy Levels: Set all data sources to "Public" (if permitted) in the Power BI Service credentials settings to allow for better query folding.
• Check Dashboard Tiles: Disable or reduce the "Cache update frequency" in the dataset settings to stop pre-refresh queries.
• Enable Query Caching: If using Power BI Premium, turn on Query Caching to reuse Athena results for identical visuals.
• Partition Data: Ensure your S3 data is partitioned. This prevents Power BI’s "small" visual queries from triggering a "full" dataset scan.
What you are seeing is expected behavior. The scheduled refresh time in Power BI Service does not control when queries are sent to the data source. The Service runs automatic background operations such as schema validation, permission checks, and internal health checks, and these can trigger query executions hours before the configured refresh window. At refresh time, Power BI may execute multiple identical queries in parallel as part of internal validation processes, and there is no guarantee of query deduplication, so each execution can result in a full scan in Athena. Settings like disabling background data preview apply only to Power BI Desktop and do not affect Service behavior. There is no way to delay, throttle, or schedule query execution from Power BI itself, so any mitigation must be done on the Athena side, for example by enabling query result reuse, reducing scanned data through partitioning and column pruning, using CTAS tables or materialized views, or setting limits via workgroups. Opening a Microsoft support ticket can be useful if you need official confirmation, but in most cases support will confirm that this is by-design behavior rather than a bug.
If this post helps, then please consider Accepting it as the solution to help the other members find it more quickly
6 Replies
- Ritaf1983
Super User
What you are seeing is expected behavior. The scheduled refresh time in Power BI Service does not control when queries are sent to the data source. The Service runs automatic background operations such as schema validation, permission checks, and internal health checks, and these can trigger query executions hours before the configured refresh window. At refresh time, Power BI may execute multiple identical queries in parallel as part of internal validation processes, and there is no guarantee of query deduplication, so each execution can result in a full scan in Athena. Settings like disabling background data preview apply only to Power BI Desktop and do not affect Service behavior. There is no way to delay, throttle, or schedule query execution from Power BI itself, so any mitigation must be done on the Athena side, for example by enabling query result reuse, reducing scanned data through partitioning and column pruning, using CTAS tables or materialized views, or setting limits via workgroups. Opening a Microsoft support ticket can be useful if you need official confirmation, but in most cases support will confirm that this is by-design behavior rather than a bug.
If this post helps, then please consider Accepting it as the solution to help the other members find it more quickly
- krishnakanth240
1.Switch to Import mode
If data latency allows
Import from Athena
Use Incremental Refresh
Refresh only new partitions✔ Eliminates repeated scans
✔ Massive cost reduction
✔ Best performance2.Use aggregated / materialized tables
In Athena
Create pre-aggregated tables or views
Partition by date
Reduce columns
Power BI queries then scan MBs, not GBs.3.Avoid Direct Query for reports
If Direct Query is mandatory
Reduce visuals
Avoid complex DAX
Avoid slicers with high cardinality
Disable auto page refresh
Avoid “show items with no data”
Still - cost will remain high.4.Consider a serving layer
Common enterprise pattern
S3 (raw)
→ Athena (batch)
→ Redshift / Aurora / Databricks SQL (serving)
→ Power BI
Athena stays for data prep, not BI. - cengizhanarslan
What you’re seeing is usually not one “refresh”. Power BI can trigger Athena queries for several different reasons, and with DirectQuery it’s easy to get multiple full scans.
Most common causes to check:
1) It’s not only the dataset refresh
Even if the scheduled refresh is 10:00, queries can run earlier due to:users opening the report / dashboard (DirectQuery executes on view)
subscriptions / email attachments
dashboard tiles / pinned visuals refreshing
cache warm-up / pre-load activity (capacity features, if you’re on Premium/Fabric)
So 6:00 AM often matches “someone or something viewed it” or a subscription time.
2) DirectQuery = multiple queries per page
At 10:00, Power BI may run multiple queries because:each visual sends its own query
slicers and filters can trigger extra queries
drilldowns/tooltip pages/conditional formatting can generate additional queries
“auto page refresh” (if enabled) repeats them
3) Query folding / native SQL pushdown isn’t the same with Athena
If your model forces complex transformations, Power BI may generate multiple similar queries that still scan a lot (and Athena charges per scan). - MohitsinghMS
Resolver II
The unexpected Athena activity is likely driven by Power BI's metadata maintenance and its multi-query engine.
Why it’s happening
• The 6:00 AM Gap: This is usually Dashboard Tile Refreshes or Cache Updates. Even if a scheduled refresh is at 10:00 AM, pinned dashboard tiles or "Automatic Page Refresh" settings trigger independent queries to check for schema or data changes.
• Multiple 10:00 AM Scans: * Visual Parallelism: Power BI executes a separate query for every visual on a page. Five charts = five Athena scans.
• Privacy Levels: If Data Privacy levels are set to "Organizational" or "Private," the engine often runs redundant queries to prevent data leakage between sources.
Quick Fixes
• Consolidate Privacy Levels: Set all data sources to "Public" (if permitted) in the Power BI Service credentials settings to allow for better query folding.
• Check Dashboard Tiles: Disable or reduce the "Cache update frequency" in the dataset settings to stop pre-refresh queries.
• Enable Query Caching: If using Power BI Premium, turn on Query Caching to reuse Athena results for identical visuals.
• Partition Data: Ensure your S3 data is partitioned. This prevents Power BI’s "small" visual queries from triggering a "full" dataset scan.
Hi sujaldhamne02 ,
I wanted to check if you had the opportunity to review the information provided by cengizhanarslan , krishnakanth240 , Ritaf1983 and MohitsinghMS . Please feel free to contact us if you have any further questions.
Thank you.May I check if this issue has been resolved? If not, Please feel free to contact us if you have any further questions.
Thank you
