<< Back

Faster, Faster! Designing for Performance: query and cache

Welcome back to the blog series Faster, Faster! We are one step deeper in our quest to understand dashboard performance and its intricacies discussed in the previous post. We now know the tools we can use to assess performance in Tableau and the question we must ask: “How can I create a fast, easy to use and future-proof report?”

To do that we must understand what is happening behind the scenes. When you drag and drop a field in Tableau, a data request, namely a query in VizQL is sent to the data source. A driver translates the query language to SQL. The data source be it a database or an extract processes multiple values and computes a single value – also known as an aggregate. This is translated back into VizQL.

A potential bottleneck in this flow of data is the data source type. It is good to know which is better for performance: to extract the data or remain live.

Data Sources

An extract is a snapshot of the data which is stored locally or on a shared network. Creating a Hyper extract means the data will be optimised for Tableau and you will leverage a fast data engine. However, you will need to set up refreshes to keep the data up-to-date, scheduling as often as every fifteen minutes.

Keeping a database or cloud connection, means having a real-time feed. However you will rely on the database for queries. If your database is slow then your dashboard will also be slow. Performance may also lag according to other factors related to the data source such as network speed or traffic.


The rendering process in Tableau is creating a dashboard layout. This involves a decision on how many axis ticks or grid lines to draw, a decision on the position for each mark label, and the number of rows and columns to display. All of these are determined by the size of the window in which the dashboard will be displayed. If you have a fixed size dashboard you can take advantage of caching – data is stored temporarily and as users view the dashboard it loads fast.

If users are consuming the reports on different sized screens, with automatic sizing or when using phone or tablet layouts, cache is not reused. Ensure the best viewing experience across multiple devices is a benefit which outweighs the impact of caching.

Enjoying the series? Post comments and retweet 🙂

Alexandra Hanna

London, UK

Leave a Reply

Your email address will not be published. Required fields are marked *