Tableau Dashboard Performance Series : Tip#3: Utilizing Tableau Extracts

So, you got access to data, you know what you need from the data source and you are off to the races, building Tableau dashboards

EXCEPT, each one of your queries takes a long time to execute on the DB.

Here are some ideas around how to get past those issues:

  1. If you are told that the DB is well tuned, but it is NOT giving you the performance you need, you need to take the situation in your hands, right? That’s when Tableau extracts can help you out.
  2. If you are given a very complicated SQL that you don’t know how to reconstruct using Tableau visual joins, go ahead and plug in the SQL into the CUSTOM SQL view, and then extract the data
  3. If you are told that the final dashboards needs to be on live data but you need to create dashboards while the DB is being tuned, extract thed ata
  4. If you need to work offline on developing something, extract the data

As you can see there are many scenarions you need to extract the data, but for some reasons, the biggest reason that I STILL see in the field is that many databases are still not tuned for modern analytics that Tableau provides. In that case, we just need to extract the data out

Tableau extracts can make a huge different to your analytical queries as it is a columnar data store. If your data privacy and policies permit, consider using extracts instead of live database connections. Most definitely helpful during dashboard design phases even when final product needs to be based on live data

PRO TIP: Hiding unused fields from the data source can make a huge impact

Read more here

Tableau Dashboard Performance Series : Tip#2: Number of Marks

The number of marks being shown in a sheet will directly impact the performance of that sheet.

Most of the dashboards are meant to provide a summary of detailed data to our audience. What is the point in having millions of data points in a dashboard

(I guess, EXCEPT, when trying to find outliers or create a density map )

so, in every situation where you can reduce the # of marks to only what you need, you will see significant change in the amount of time it takes to create that view

Read more in the my previous post about tabular data

Tableau Dashboard Performance Series : Tip#9: Custom SQL

Custom SQL can have a HUGE impact on the performance of your visuals for the live connections.

If you are using extracts, there will be no impact to the dashboard performance. But, for live connections, Custom SQL can be really deadly

Watch the clip from my youtube video about Custom SQL

Here is the full recording

Custom SQL can be a nightmare to troubleshoot as well

In general, my guidance is as follows

  1. AVOID at all costs if your analysis is LIVE against a data source
  2. AVOID at all costs if your analysis is querying a data source LIVE (oh, I guess I already said that above. Anyway, was worth repeating)
  3. In the case of extract option, the Custom SQL doesn’t affect your dashboard performance at all but it might impact your extract creation time

Tableau Dashboard Performance Series : Tip#1: Tabular Data

This just happens to one of the biggest reasons for bad performance. Tableau is meant to provide you visibility into your data in a way that you can interact with it.

Long gone are the days when you NEEDED to create long tabular reports to have access to all your data

Just reducing the amount of data displayed at the row level, makes a huge difference.

Go to this tip in my TC19 session

Below is an example of how using “Guided Navigation” principles allows you to show the tabular data only for a certain slice can help improve performance

Tableau Dashboard Performance Series : Tip#6: Sorting

alright, so you want to see the list of your Top 100 customers

Top 100 Customers sorted based on “# of products purchased”

A valid scenario and a reasonable request

Here are those two views (same list of customers just sorted differently)

This slideshow requires JavaScript.


Sorting can have an impact on performance as well, especially, when the metric by which we are sorting has no business relevance and is not already included in the query Tableau is going to execute. There are certain situations where a specific sort is needed, but I have often found that the most important sort on a bar chart is typically the sort by metric that the bar is already displaying. No need to “dual-code” the information

Watch this the clip from the Youtube video about sorting to learn more