Most people who use Tableau every day think of it as a canvas: you drag a field onto Rows, another onto Columns, drop a measure on Color, and a chart appears. That ease is the whole point — and it's also why so few users can explain why one workbook is instant and another spins for thirty seconds on the same data. The drag-and-drop surface hides a real system underneath: a language that turns your gestures into queries, an engine that answers them, and a renderer that draws the result. Once you can see those three pieces, slow workbooks stop being a mystery.
The piece that makes Tableau Tableau is VizQL — the visual query language that compiles what you build on the shelves into both a data query and a set of drawing instructions. Underneath it sits a data layer that is either a live connection to your database or an extract powered by the new Hyper engine. I'll trace how a viz becomes a query, what Hyper changed in early 2018, and the one number — marks — that governs performance.
VizQL: the language behind the drag and drop
VizQL is a declarative language that maps a visual specification to a database query and a rendering. When you place fields on shelves — Columns, Rows, and the Marks card (Color, Size, Label, Detail) — Tableau isn't just styling a chart. It's building a VizQL statement that describes what you want to see, and VizQL works out the SQL (or MDX, for cubes) needed to fetch it and how to draw the marks that result. You declare the picture; VizQL figures out the data.
The crucial consequence is how aggregation works. The dimensions you put on shelves define the level of detail of the view — the grain at which Tableau groups the data — and measures are aggregated to that grain. Put Region on Rows and SUM(Sales) on Columns and VizQL generates roughly SELECT region, SUM(sales) FROM orders GROUP BY region. Add Category to Detail and the GROUP BY grows and you get more marks. You are, in effect, writing GROUP BY clauses by dragging pills — without ever seeing the SQL.
graph TD
SHELF["Shelves & Marks card
(dimensions, measures, encodings)"]
VIZQL["VizQL compiler
builds the visual spec"]
Q["Generated query
SELECT dims, AGG(measures)
GROUP BY dims"]
DATA["Data layer:
live source OR Hyper extract"]
AGG["Aggregated result set
(one row per mark)"]
REND["Rendering: draw marks
(position, color, size, label)"]
SHELF --> VIZQL --> Q --> DATA --> AGG --> REND
How a viz becomes a picture. VizQL turns the fields on your shelves into an aggregate query at the view's level of detail, runs it against the data layer, and renders one mark per row of the result. The shape of the view — which dimensions are in play — decides both the query's GROUP BY and how many marks get drawn.
Live vs extract: the data layer underneath
VizQL needs something to query, and Tableau gives you two choices that change everything about performance and freshness. A live connection sends VizQL's generated SQL straight to your source database (SQL Server, Redshift, Oracle, and so on) on every interaction — so the data is always current and as fast as that database is, with its load landing on it. An extract instead pulls the data out once into Tableau's own optimized file, and from then on VizQL queries the extract rather than the source.
The trade is the familiar one: live means freshness and pushes work (and load) onto the source; extract means speed and isolation at the cost of staleness between refreshes. The reason extracts are usually faster isn't magic — it's that the extract is stored in a columnar, in-memory-friendly engine purpose-built for analytical queries, which most operational source databases are not.
Hyper: the new engine behind extracts
Here's what makes this an interesting moment to write about Tableau internals: as of version 10.5 (shipped in January 2018), the extract engine is Hyper, replacing the older TDE (Tableau Data Engine). Hyper came out of academic research into high-performance database systems, and Tableau acquired it and made it the default. The headline change is that the same extract is dramatically faster to query and to build.
What Hyper does differently:
- Columnar storage. Extract data is stored by column, so a query reads only the columns it references — the same principle that makes analytical databases fast — and compresses well.
- A real query engine. Hyper is a full in-memory database with a query optimizer, not just a cache. It compiles queries to efficient machine code and uses all your CPU cores, so complex aggregations that crawled on the old engine come back quickly.
- Faster extract creation and incremental refresh. Building and refreshing extracts is markedly quicker, which matters when extracts feed scheduled refreshes on Tableau Server.
The practical upgrade note for early 2018: migrating a workbook to a .hyper extract (from the old .tde) is mostly automatic when you move to 10.5, and you usually feel it most on large extracts and heavy aggregations. If a dashboard was slow because the old data engine struggled with a big extract, re-creating it on Hyper is often the cheapest win available — before you touch a single calculation.
Tracing one interaction
Put the pieces together with a single click. You filter a dashboard to one region. That interaction changes the VizQL spec, so VizQL regenerates the query for each affected worksheet — now with a WHERE region = 'West' added. Each query goes to the data layer: if you're on an extract, Hyper answers it in memory; if live, the source database does. The aggregated rows come back — one row per mark — and Tableau renders the marks, applying the encodings (color, size, label) from the Marks card. Every worksheet on the dashboard repeats this. The total time is the sum of querying plus rendering across all of them.
That last sentence is the whole performance model. Two things cost time: the queries (how heavy, how many, against what) and the rendering (how many marks). Everything you'll ever tune comes back to one or the other.
The number of marks is the performance lever people miss. A view's mark count is the rows its level of detail produces — and it's easy to explode without realizing. Put a high-cardinality dimension (order ID, customer, timestamp) on Detail and you can turn a 12-mark bar chart into a 200,000-mark scatter that the browser has to draw. The query may even be fine; the rendering is what's dying. When a viz is slow, the first thing I check is the mark count in the lower-left status bar. Aggregate higher, drop the high-cardinality pill off Detail, or split the view — almost always faster than any clever calculation.
What to carry away
Tableau is three systems wearing one friendly coat. VizQL compiles the fields on your shelves into an aggregate query at the view's level of detail and into instructions for drawing marks — so dragging pills is really writing GROUP BY clauses. The data layer is either a live connection (fresh, source-bound) or an extract, and as of 10.5 that extract runs on Hyper, a columnar in-memory engine that makes extracts query and build much faster. And the renderer draws one mark per result row, which is why mark count — not just query complexity — decides whether a dashboard feels instant.
Hold that model and Tableau performance stops being guesswork: ask whether the bottleneck is the query (push toward an extract on Hyper, simplify the data) or the rendering (cut the marks). In a follow-up I'll turn this into a concrete playbook — extracts, calculations, and dashboards that stay fast as the data grows.