Tableau Architecture Diagram & Server Components
David Carter
⚡ Smart Summary
Tableau Server Architecture connects desktop, web, and mobile clients to many data tiers through a layered, multi-process design. This page explains each layer, the request path through the server, the individual background processes, and single-node against multi-node deployment.
Tableau Server is designed in a way to connect many data tiers. It can connect clients from desktop, mobile, and web. Tableau Desktop is a robust data visualization tool. It is highly available and secure.
It can run on both virtual and physical machines. It is a multi-user, multi-process and multi-threaded system.
Providing such powerful features requires a robust architecture. Let’s study the Tableau Server Architecture in this tutorial.
Tableau Server Architecture
The various layers used in the Tableau server are given in the following architecture diagram
Reading the diagram from the bottom up, the data sources sit at the base, the connectors sit above them, the server components occupy the middle, and the clients sit at the top. Each of the five sections below covers one of those bands.
Let’s study the different components of Tableau Architecture
Data Server
The primary component of Tableau Architecture is the Data sources it can connect to it. Note that this first layer refers to the data tier as a whole; the Data Server process that runs inside Tableau Server is described separately under “Components of Tableau Server” below.
Tableau can connect to multiple data sources. These data sources can be on-premise or remotely located. It can connect to a database, excel file, and a web application all at the same time. Tableau can connect data from heterogeneous environments. It can blend the data from multiple data sources. It can also make the relationship between various types of data sources.
Data Connectors
The Data Connectors provide an interface to connect external data sources to Tableau Data Server.
Tableau has in-built ODBC/SQL connector. This ODBC Connector can connect to any databases without using their native connector. Tableau has an option to select both live and extract data. Based on the usage, one can be easily switched between extracted and live data.
- Live Connection or Real time data: Tableau can connect to real time data by linking to the external database directly. It uses the infrastructure of existing database system by sending dynamic MDX (Multidimensional Expressions) and SQL statements. This feature can link to the live data with Tableau rather than importing the data. It makes good the investment done by an organization on a fast and optimized database system. In many enterprises, the size of the database is huge and is updated periodically. In those cases, Tableau works as a front-end visualization tool by connecting to the live data.
- Extracted or In-memory data: Tableau has an option to extract the data from external data sources. We can make a local copy in the form of a Tableau extract file, which uses the .hyper format produced by the Hyper data engine. It can extract millions of records into that engine with a single click. Tableau’s data engine uses memory and disk together to store and process data. Using filters, Tableau can extract few records from a huge dataset. This improves the performance, especially while working on massive datasets. Extracted or in-memory data allows the users to visualize the data offline, without connecting to the data source.
Components of Tableau Server
The different components present in a Tableau server are:
- Application Server
- VizQL Server
- Data Server
A) Application Server:
The application server is used to provide the authentications and authorizations. It handles the administration and permission for web and mobile interfaces. It assures security by recording each session id on Tableau Server. The administrator can configure the default timeout of the session in the server.
B) VizQL Server:
VizQL server is used to convert the queries from the data source into visualizations. Once the client request is forwarded to VizQL process, it sends the query directly to data source and retrieves information in the form of images. This image or visualization is presented to the user. Tableau server creates a cache of visualization to reduce the load time. The cache can be shared across many users who have the permission to view the visualization.
C) Data Server:
Data server is used to manage and store the data from external data sources. It is a central data management system. It provides metadata management, data security, data storage, data connection and driver requirements. It stores the relevant details of data set such as metadata, calculated fields, sets, groups, and parameters. The data source could extract data as well make live connections to external data sources.
Gateway
The gateway channelizes the requests from users to Tableau components. When the client makes a request, it is forwarded to external load balancer for processing. The gateway works as a distributor of processes to various components. In case of absence of external load balancer, gateway also works as a load balancer. For single server configuration, one primary server or gateway manages all the processes. For multiple server configurations, one physical system works as primary server while others are used as worker servers. Only one machine can be used as a primary server in Tableau Server environment.
Clients
The dashboards and visualizations in Tableau server can be viewed and edited using different clients. The Clients are Tableau Desktop, web browser and mobile applications.
| Clients | Environment |
|---|---|
| Tableau Desktop | Tableau Desktop is a business analytics tool. It helps to create, view and publish dashboards in Tableau Server. Users can access various data sources and build visualizations in Tableau Desktop. |
| Mobile | The dashboards from the server can be interactively visualized using mobile browsers and applications. The browser and application can be used to view and edit the contents in the workbook. |
| Web | Web browsers such as Google Chrome, Safari, Firefox and Microsoft Edge support the Tableau server. The contents and visualizations in the dashboard can be edited through these web browsers. |
Naming the layers explains what exists. The next section follows a single request through all of them so the sequence becomes concrete.
How a Tableau Server Request Flows End to End
Opening a published dashboard triggers a chain of handoffs between the components described above. Following that chain is the fastest way to understand why a view feels slow and which process to inspect first.
- Request arrives at the gateway. A browser, mobile app, or Tableau Desktop client sends an HTTPS request. If an external load balancer is present it picks a node; otherwise the gateway on the primary node performs that role itself.
- Application Server checks identity and permission. The request is passed to the Application Server process, which validates the session, confirms the user has rights to the workbook, and records the session identifier.
- Cache Server is consulted. Before any query runs, the server checks its shared query cache. A matching entry means the visualization returns immediately and the remaining steps are skipped, which is why the second person to open a dashboard usually waits far less than the first.
- VizQL builds the query. On a cache miss, the VizQL process translates the visual specification stored in the workbook into a query for the underlying source.
- Data Server resolves the connection. If the workbook uses a published data source, the Data Server supplies the connection details, calculated fields, groups, and sets. A live connection sends the query onward to the external database; an extract is answered from the Hyper data engine using the .hyper file held in the File Store.
- Results are rendered and returned. VizQL turns the result set into the marks, axes, and labels of the view, hands the rendered output back through the gateway, and writes the result into the cache for the next user.
Two points in that chain deserve attention when tuning. First, an extract answered locally avoids a round trip to a busy production database entirely. Second, a well-populated cache converts most repeat views into a single lookup, so restarting the server or publishing a new workbook version deliberately clears that advantage until the cache warms again.
Several of the processes named above never appear in the layered diagram, and the table below identifies them.
Tableau Server Process Types and What Each One Does
A Tableau Server installation runs a set of named processes side by side. Administrators see them individually in the Tableau Services Manager status page, so recognising each one makes troubleshooting far quicker.
| Process | Responsibility |
|---|---|
| Gateway | Receives every inbound request and routes it to the correct node and process. |
| Application Server | Handles sign-in, permissions, search, browsing, and the administrative interface. |
| VizQL Server | Loads and renders views by translating the visual specification into queries. |
| Data Server | Manages published data sources, metadata, and connection credentials. |
| Data Engine (Hyper) | Creates and queries .hyper extracts held on the node. |
| Backgrounder | Runs scheduled work: extract refreshes, subscriptions, alerts, and flow runs. |
| Repository | A PostgreSQL database holding workbook metadata, users, permissions, and usage history. |
| File Store | Stores extract files and replicates them across nodes that need them. |
| Cache Server | A shared in-memory query cache used by VizQL, Data Server, and Backgrounder. |
| Cluster Controller | Monitors process health and triggers failover, for example promoting a passive repository. |
| Coordination Service | Keeps configuration and topology consistent across every node in the cluster. |
Backgrounder deserves particular notice because it is the process most often starved of capacity. Extract refreshes and subscription emails compete for the same workers, so a morning full of overlapping schedules delays both.
Single-Node vs Multi-Node Tableau Server Deployment
Every process listed above can run on one machine, and for a small team that is the normal arrangement. A single-node installation is simple to patch and monitor, but it offers no redundancy: if the machine stops, so does every dashboard, and heavy extract refreshes compete directly with people viewing content.
A multi-node cluster spreads the same processes across two or more machines that share one repository and one topology. Roles are then assigned deliberately rather than by default.
- Separate the backgrounder. Moving extract refreshes onto a dedicated node stops overnight jobs from slowing interactive views.
- Duplicate the gateway. Running a gateway on more than one node, behind an external load balancer, removes the single entry point as a failure risk.
- Add a passive repository. A second repository instance allows the Cluster Controller to fail over automatically if the active copy stops responding.
- Scale VizQL for concurrency. More VizQL instances serve more simultaneous viewers, which is the usual bottleneck once adoption grows.
- Keep File Store close to Data Engine. Nodes that query extracts need a local copy, so these two are normally colocated.
The practical trigger for moving to multiple nodes is rarely raw data volume. It is usually either a business requirement for high availability or a refresh window that no longer fits inside the quiet hours.
