Atualmente, utilizo a ferramenta Amazon QuickSight para a construção de um dashboard. Esse dashboard é composto por 46 cards, sendo:
36 KPIs,
8 gráficos do tipo medidor,
2 tabelas.
Os dados representam evoluções associadas a um UUID distinto, o que me permite analisar a situação de cada UUID de acordo com a data de referência selecionada no filtro. Além disso, utilizo a funcionalidade de sensibilização (Actions → Filter): quando o usuário clica em um card que representa um determinado status, o UUID correspondente é automaticamente filtrado na tabela abaixo, possibilitando a extração de informações mais detalhadas.
Atualmente, estou enfrentando um problema significativo que está impactando diretamente a usabilidade do dashboard. O dataset contém dados desde dezembro de 2025 até a data atual, totalizando aproximadamente 100 GB e 73 milhões de linhas. Quando o usuário seleciona um período no filtro de data, o QuickSight entra em processamento por um longo tempo e, em muitos casos, falha antes de retornar o resultado.
Diante desse cenário, gostaria de entender quais são as possíveis soluções para esse problema de performance. Existe alguma forma de otimizar ou aumentar a performance do SPICE no QuickSight, seja por meio de configuração, arquitetura de dados ou ajuste de serviço?
So with 73 million rows and 100GB, you may be pushing what SPICE can handle, especially with the way your dashboard is set up. I think the issue may not just be regarding the data size, but also that you’ve got two layers of filtering happening: the date range filter plus the UUID filtering through card actions. Honestly without working in your environment, it is hard to tell if this problem is related to SPICE volume, how you are interacting with the data on the dashboard (i.e. filters), or could be a mix of both.
A few things to note for data volume is check if you’re loading columns you don’t actually need. High-cardinality text fields especially can kill performance, so if there’s anything you’re not using in those 46 visuals, cut it out (Quicksight Spice Capacity & data load - Q&A - Amazon Quick Community).
Additionally, one thing to note is that there is a 50 visual limit for each sheet in Quick Sight. Now while you are not at the limit, the closer you are to the limit can sometimes make your dashboard act wonky.
Another potential solution could be breaking this up. One big dashboard with 46 cards is a lot to ask from a single dataset. Maybe split it into a few smaller ones like KPIs in one, detailed tables in another. This can sometimes increase performance.
Additionally, one thing to note is to make sure you’ve got enough SPICE capacity allocated. Auto-purchase can save you from hitting limits during refreshes (Configure SPICE memory capacity - Amazon Quick).
Honestly though, with that many rows and the UUID filtering happening when people click cards, you might just be hitting the limits of what SPICE can handle smoothly. While SPICE technically supports up to 2 billion rows now, performance at that scale really depends on how the data is structured and queried. Sometimes the answer isn’t optimizing what you have, it’s restructuring how you’re approaching the problem. Moreover, if these don’t help enough, might be worth looking at whether direct query could work for some of this; however, direct query may offer different issues.
Just checking back in since we haven’t heard from you in a bit. I wanted to see if the guidance shared earlier helped resolve your question, or if you found a solution in the meantime.
If you still have any additional questions related to your initial post, feel free to share them. Otherwise, any update you’re able to provide within the next 3 business days would be helpful for the community.
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.
