BI connectivity
Tableau reads the lakehouse — with no second permission model
The usual BI connections hang off a technical account that may see everything. Reports then run under a different permission model than the platform — and two permission models drift apart. This connection has none of its own: it passes the analyst's identity through.
- Status
- Tableau and Power BIIn development
- Route
- Tableau's REST connector (2023.3+)
- Formats
- JSON or CSV over HTTP GET
- Rights
- delegated, no service account
- As shipped
- switched off
No custom Tableau plugin — deliberately
Tableau's own extension routes for web data have run out: Web Data Connector 2.x was removed in Tableau 2023.1, and WDC 3.0 is deprecated. Tableau's own recommended successor is the REST API Connector from the Tableau Exchange — a connector Tableau builds and signs, which reads an HTTP GET endpoint returning JSON or CSV.
So our side of this connection is not a plugin that would need maintaining and signing, but exactly the endpoint Tableau's official connector expects. Side effect: the same feed is readable from other tools with no extra work.
| Endpoint | For |
|---|---|
| /tableau/info | self-description: endpoints, limits, auth, JSONPath |
| /tableau/schema | columns of a table or view, with Tableau data types |
| /tableau/rows | one page of data, as JSON or CSV |
The same chain, no parallel route
This is where the connection differs from an ordinary one. It does not reimplement the permission model, it uses it.
Bearer verification -> user
token exchange (RFC 8693, aud=trino) -> that identity
Trino: grants + row access + masking -> that slice
WORM audit chain (thread_id "tableau") -> traceable- No service account — the schema lookup runs under the analyst's exchanged token too
- Someone who may not see a table in Trino gets a 404 here
- Someone who may see it sees exactly the rows and columns their policies allow
- No caller SQL: the URL carries only catalog, schema, table, paging parameters and sort columns
- Read-only — what is generated is structurally a SELECT with ORDER BY, OFFSET and LIMIT
A BI route with its own permission model is a second truth about who may see what. This one has none.
Traceable down to the single page
Every data fetch writes an entry into the audit chain — one per page, value-free: target object, paging parameters, format. An extract in Tableau is therefore fully reconstructable, including the attempts Trino rejected. Responses go out as “no-store”, so governed data is not left sitting in any cache along the way.
Metrics instead of joins
The feed knows not only tables and views but the curated metrics of the semantic layer. A semantic view — a metric with stored joins — therefore reaches Tableau as one flat table, without the analyst needing to know the joins.
?catalog=…&schema=…&table=… a table or view
?metric=<name>[&dimension=…] a curated metricOff as shipped
A BI connection is a data export path. A platform administrator should decide on it deliberately, not inherit a default. The switch therefore lives in the console, is stored in the database rather than an environment variable, is recorded in the WORM chain, takes effect without a restart — and is off as shipped. Off means the schema and data endpoints answer 403, regardless of the caller's rights.
- A per-page row cap that can only lower the hard limit in code — a larger value is rejected, not silently clamped
- A catalog allowlist as a second barrier in front of Trino: it answers which data may leave the building toward BI at all
- The allowlist does not replace permissions — someone who may not see a catalog in Trino still cannot, even if the list names it
See it instead of reading about it
In half an hour we walk through the platform against your questions — ingestion, permissions, search, agent. No slides.
Book a live demo