Faster, Faster! Designing for Performance: query and cache

11 February 2019

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.

Cache

The rendering process in Tableau is creating a dashboardlayout. 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 columnsto display. All of these are determined by the size of the window in which thedashboard will be displayed. If you have a fixed size dashboard you can takeadvantage of caching - data is stored temporarily and as users view thedashboard 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 :)

Author:
Sasha Hanna
1st Floor, 25 Watling Street, London, EC4M 9BR
Subscribe
to our Newsletter
Get the lastest news about The Information Lab and data industry
Subscribe now
© 2025 The Information Lab