We are currently facing an intermittent SPICE ingestion performance issue in our QuickSight .
We have a total of 12++ datasets/views configured, and historically all datasets used to refresh successfully in parallel within approximately 1–2 minutes.
However, starting from Saturday, multiple datasets/views have started experiencing unusually long SPICE ingestion times. The issue is not occurring on a single fixed dataset. Different datasets are getting impacted on different days, while some datasets continue to refresh normally.
For example:
On Saturday, one dataset took around 57 minutes to refresh.
On Sunday, a different dataset showed the same behavior.
Today, another dataset is experiencing similar delays.
Key observations:
Some datasets are refreshing successfully within the normal timeframe.
Some datasets are randomly taking 40–60 minutes for SPICE ingestion.
Dataset row counts appear relatively stable.
Earlier, all datasets refreshed quickly in parallel without any issue.
The behavior started suddenly from Saturday.
We have attached screenshots from the QuickSight refresh history for reference.
We would like to understand:
Whether this could be related to SPICE ingestion concurrency or throttling.
If there are any known QuickSight/SPICE performance issues recently.
Whether there are any recommended diagnostics or monitoring steps from the QuickSight side.
A significant portion of the overall SPICE refresh duration is driven by the time taken to execute the source query (i.e., fetching data from your underlying data source), rather than the data transfer into SPICE itself. When multiple datasets are scheduled to refresh at the same time, they may get internally queued, which can add to the total end-to-end refresh time.
Since you have 12+ datasets refreshing in parallel, we recommend staggering the refresh schedules by 5-10 minutes between datasets. This helps reduce concurrency pressure and minimizes the likelihood of internal queuing delays.
To isolate whether the delay is occurring at the SPICE layer or at the data source layer, we recommend reviewing the performance of the source queries during the affected time windows.
Could you please confirm which data source your datasets are connected to (e.g., Athena, Redshift, RDS, or another source)?
If you are using Amazon Athena, please perform the following check:
Open the Athena console → navigate to the Recent queries tab.
Filter by the timestamps corresponding to the slow SPICE refreshes.
For each matching query, compare the following metrics:
Queue time - How long the query waited before execution started
Execution time - How long the query took to run once started
Data scanned - How much data Athena read from S3
If you are using Amazon Redshift, please review the query history for the corresponding time window and check for any queuing or elevated execution times.
This will help to determine whether the delays are due to source-side contention (e.g., Athena queue wait times) versus SPICE-side queuing.
I spent a few hours monitoring the executions directly in Trino, and the queries are running normally and finishing very quickly. However, starting this past weekend, QuickSight began showing extremely high refresh times.
Most of these processes have been running with the same pattern for almost 1 year, and I had never seen this behavior before.
I will attach:
An example of an execution with excessive delay;
A list of execution times extracted on 05/08/2026, where some abnormal execution times had already started to appear;
The report extracted today, where the issue became even more evident.
Based on the observed behavior, it seems that the query finishes normally on the engine side, but QuickSight gets stuck in some later stage such as processing, indexing, or writing into SPICE.
Note: There is one specific point where I had already noticed strange behavior before: the new QuickSight experience released recently. During my tests, processes that normally completed in around 26 seconds started taking approximately 2 minutes in the new version. Because of that, I decided not to migrate my processes to it.
We are also facing the same issue since Friday. Runs that typically take seconds are taking 20 minutes and larger datasets with typically several minute refreshes are upwards of an hour. Nothing out of the norm on the database side. This is clearly an aws issue not on the user.
Just to add from our side, we have already performed a deep-dive investigation on the Snowflake data source. The views/queries are executing normally and are completing within seconds to a few minutes, with no noticeable queueing or performance degradation observed at the source layer.
Based on this, it does not appear that the delay is originating from Snowflake or query execution time. The issue seems to be occurring during the AWS QuickSight SPICE ingestion/refresh process, where the refresh duration is significantly higher compared to the actual source execution time.
We also observed that this issue is not specific to any particular view or table. The delay is occurring randomly across different datasets:
Yesterday, around 6 views experienced significant delay in refresh time.
Today, some of those same views are refreshing normally within 2–3 minutes as expected, while other views that were fine yesterday are now taking longer.
There are also some views that are consistently slow on both days.
FYI, we have also attached a screenshot from the Snowflake as well as Quicksight side showing that query execution is normal there, but the corresponding QuickSight SPICE refresh is taking significantly longer.
This inconsistent and shifting behavior across datasets further suggests it is not tied to a specific query or data source.
We are continuing to investigate from our side, but so far we have not been able to identify a definitive root cause. We will keep monitoring and share any further findings.
I would recommend filing a case with AWS Support where we can dive into the details so that we can help you further. Here are the steps to open a support case. If your company has someone who manages your AWS account, you might not have direct access to AWS Support and will need to raise an internal ticket to your IT team or whomever manages your AWS account. They should be able to open an AWS Support case on your behalf.
Hello, just wanted to follow up if the team has found the root cause of the refresh issue from the past few days?
The issue seems to be fixed today, but it would be helpful to understand what happened. Thanks.
Just checking back in since this thread hasn’t received a response in a while. Were you able to follow Xclipse’s suggestion of creating a support ticket, or has the issue resolved itself for you like it did for irinaaaaa? Please help the community by following up in general within the next 3 business days!
Since I haven’t received any further updates from you, I’ll treat this inquiry as complete for now. If you have any additional questions, feel free to create a new post in the community and link this discussion for context.
