When you use Databricks as a data source with Tableau, you can provide powerful interactive analytics, bringing the contributions of your data scientists and data engineers to your business analysts by scaling to massive datasets using the Databricks Runtime.

You can connect Tableau to your Databricks clusters using the dedicated Spark connector provided and maintained by Tableau.

About Tableau

Tableau provides four distinct tools:

  • Tableau Desktop: Tableau Desktop runs on local machines and can be used to connect to raw data sources and manipulate that data into views, dashboards, and more.
  • Tableau Server: Tableau Server is like Desktop except that it allows multiple users to access a centrally-managed Tableau deployment and enables data source governance.
  • Tableau Online: The cloud version of Tableau Server.
  • Tableau Prep: A tool for connecting to a variety of data sources and combining, shaping, and cleaning your data for Tableau Desktop.

For more information about Tableau, see the Tableau tutorial videos.

Connect Tableau and Databricks


  • Tableau Desktop, Tableau Server, or Tableau Online
  • Simba Spark ODBC driver version 1.2.0 or above
Tableau installs this driver by default in recent versions of Tableau (2018.1+). Therefore you might already have the required driver installed on your computer. If the driver is not installed on your computer, Tableau displays a message in the connection dialog box with a link to the Driver Download page where you can find driver links and installation instructions.


If you are using both Tableau Desktop and Tableau Server, they must use the same Spark ODBC driver version.

Connect to Databricks clusters

  1. In Databricks, get your cluster server hostname, port, and HTTP path using the instructions in Construct the JDBC URL.
  2. Launch Tableau, go to the Connect menu, click To a server > More..., and select Spark SQL.
  3. Enter your cluster’s server hostname and port.
  4. In the Type drop-down, select SparkThriftServer.
  5. In the Authentication drop-down, select Username and Password.
  6. In the Transport drop-down, select HTTP.
  7. Use your Databricks username and password. You can also use “token” as the username and a personal access token as the password.
  8. Enter your cluster’s HTTP Path.
  9. Click Sign In.

Databricks clusters expose JDBC and ODBC connections via HTTPS.

Best practices and troubleshooting

The two fundamental concepts when it comes to optimizing Tableau are:

  • Reducing the number of records being queried and visualized in a single chart or dashboard.
  • Reducing the number of queries being sent by Tableau in a single chart or dashboard.

Deciding which to try first depends on your particular dashboard. If you have a number of different charts for individual users all in the same dashboard, it’s likely that Tableau is sending too many queries to Databricks. If you only have a couple of charts but they take a long time to load, there are probably too many records being returned by Databricks to load effectively.

Tableau Performance Recording, which is available on both Tableau Desktop and Tableau Server, can help you understand where performance bottlenecks are by identifying processes that are causing latency when you run a particular workflow or dashboard.

Enabling performance recording is the first step to debugging any Tableau issue.

For instance, if query execution is the problem, you know it has to do with the Data Engine process or the Data Source that you are querying. If the Visual Layout is performing slowly, you know that it is the VizQL.

If the performance recording says that the latency is in Executing Query, it is likely that too much time is taken by Databricks returning the results or by the the ODBC/Connector overlay processing the data into SQL for VizQL. When this occurs, you should analyze what you are returning and attempt to change the analytical pattern to have a dashboard per group, segment, or topic instead of trying to cram everything into one dashboard and relying on Quick Filters.

If the poor performance is caused by sorting or visual layout, the problem may be the number of marks the dashboard is trying to return. Databricks can return one million records quickly, but Tableau may not be able to compute the layout and sort the results. If this is a problem, aggregate the query and drill into the lower levels. You can also try a bigger machine, since Tableau is only constrained by physical resources on the machine on which it is running.

For an in-depth tutorial on the performance recorder, see the Tableau help article Create a Performance Recording.

Performance on Tableau Server vs Tableau Desktop

In general, a workflow that runs on Tableau Desktop will not be any faster on Tableau Server. A dashboard that doesn’t execute on Tableau Desktop won’t execute on Tableau Server. This is important to keep in mind.

In fact, getting things working on Desktop is a much better troubleshooting technique, because Tableau Server has more processes to consider when you troubleshoot. And if things work in Tableau Desktop but not in Tableau Server, then you can safely narrow the issue down to the processes in Tableau Server that aren’t in Tableau Desktop.


By default, the parameters from the connection URL override those in the Simba ODBC DSN. There are two ways you can customize the ODBC configurations from Tableau:

  • .tds file for a single data source:

    1. Follow the instructions in this Tableau help topic to export the .tds file for the data source.
    2. Find the property line odbc-connect-string-extras='' in the .tds file and set the parameters. For example, to enable AutoReconnect and UseNativeQuery, you can change the line to odbc-connect-string-extras='AutoReconnect=1,UseNativeQuery=1'.
    3. Reload the .tds file by reconnecting the connection.

    For Databricks Runtime 3.5 and above, the cluster driver is optimized to use less heap memory for collecting large results, so it can serve more rows per fetch block than Simba ODBC’s default. Append RowsFetchedPerBlock=100000' to the value of the odbc-connect-string-extras property.

  • .tdc file for all data sources:

    1. If you have never created a .tdc file, you can add TableauTdcExample.tdc to the folder Document/My Tableau Repository/Datasources.
    2. Add the file to all developers’ Tableau Desktop installations, so that it works when the dashboards are shared.

Optimizing charts (worksheets)

There are a number of tactical chart optimizations that can help you improve the performance of your Tableau worksheets.

For filters that don’t change often and are not meant to be interacted with, use context filters, which speed up execution time. Another good rule of thumb is to use if/else statements instead of case/when statements in your queries.

Tableau can push down filters into data sources, which can greatly speed up query speeds. See this Tableau KB article and this Tableau help topic for more information about data source push down filters.

It is best to avoid table calculations if you can, because they need to scan the full dataset. For more information about table calculations, see this Tableau help topic.

Optimizing dashboards

Boiling the ocean is a common problem with Tableau dashboards. Below are a number of tips and troubleshooting exercises you can leverage to improve the performance of your Tableau dashboard.

A common source of issues with Tableau dashboards connected to Databricks is the use of Quick Filters on individual dashboards that serve a number of different users, functions, or segments. Global Quick Filters can be attached to all of the charts on the dashboard. It’s a great feature, but one that can quickly cause problems. One global quick filter on a dashboard with five charts will cause a minimum of 10 queries to be sent to Databricks. This can spiral to greater numbers as more filters are added and can cause massive performance problems, because Spark is not built to handle many concurrent queries starting at the same exact moment. This becomes more problematic when the cluster you are using is not large enough to handle the high volume of queries.

As a first step, we recommend that you use Tableau Performance Record to troubleshoot what might be causing the issue.

If the poor performance is caused by sorting or visual layout, the problem may be the number of marks the dashboard is trying to return. Databricks can return one million records quickly, but Tableau may not be able to compute the layout and sort the results. If this is a problem, aggregate the query and drill into the lower levels. You can also try a bigger machine, since Tableau is only constrained by physical resources on the machine on which it is running.

For information about drilling down in Tableau, see this Tableau tutorial.

In general, seeing many granular marks is often a poor analytical pattern, because it doesn’t provide insight. Drilling down from higher levels of aggregation makes more sense and reduces the number of records that need to be processed and visualized.

Using actions to optimize dashboards

To drill from group to segment to topic in order to obtain the same analysis and information as the “ocean boiled” dashboard, you can use Tableau actions. Actions allow you to click on a mark (for example a state on a map) and be sent to another dashboard that filters based on the state you click on. This reduces the need to have many filters on one dashboard and reduces the number of records that need to be generated, because you can set an action to not generate records until it gets a predicate to filter on.

For more information, see the Tableau help topic Actions and the Tableau blog article 6 Tips to Make Your Dashboards More Performant.


Caching data is a good way to improve the performance of worksheets or dashboards.

Caching in Tableau

Tableau has four layers of caching before it goes back to the data, whether that data is in a live connection or an extract:

Tiles: If someone is loading the exact same dashboard and nothing changes, then Tableau tries to reuse the same tiles for the charts. This is similar to Google Maps tiles.

Model: There are mathematical calculations used to generate visualizations in the event that tiles can’t be used. Tableau Server attempts to use the same models.

Abstract: Aggregate results of queries are stored as well. This is the third “defense” level. If a query returns Sum(Sales), Count(orders), Sum(Cost), in a previous query and a future query wants just Sum(Sales), then Tableau grabs that result and uses it.

Native Cache: If the query is the exact same as another one, Tableau uses the same results. This is the last level of caching. If this fails then Tableau goes to the data.

Caching frequency

Tableau has administrative settings for caching more or less often. If the server is set to Refresh Less Often, Tableau keeps data in the cache for up to 12 hours. If it is set to Refresh More Often, Tableau goes back to the data on every page refresh.

Customers who have the same dashboard being used over again – for example, “Monday morning pipeline reports” – should be on a server set to Refresh Less Often so that the dashboards all use the same cache.

Cache warming

In Tableau you can warm the cache by setting a subscription for the dashboard to be sent before you want the dashboard viewed. This is because the dashboard needs to be rendered in order to generate the image for the subscription email. See the Tableau article, Warming the Tableau Server Cache Using Subscriptions.`

Caching in Databricks

You can cache popular tables or critical tables before users consume Tableau dashboards to reduce the time it takes for Databricks to return the results to Tableau.

You can run scripts in the morning to select cache for specific tables or use Delta cache on virtual machines that are optimized for caching.

You can even cache specific queries that Databricks gets from the driver.