- Home
- Tableau
Beside Tableau, not instead of it — yet
Using datapipelines with Tableau: what it does today, and what is planned
Tableau is very good at drawing. What costs teams the money is everything before the drawing — getting a trustworthy, joined, refreshed dataset in front of it from four databases and a bucket — and everything after it: putting the result inside their own product instead of a portal. datapipelines does the first part today, with an AI agent doing the authoring and a person doing the releasing. The second part is planned, and this page keeps the two apart.
The pattern we keep seeing
Six figures for a workbook nobody can embed
A company buys Tableau, hires a consultancy, and gets beautiful dashboards over a dataset that took three months of Prep flows, a warehouse nobody wanted, and a nightly job that breaks on the first schema change. Then product asks for the same numbers inside the app customers log into. The workbook cannot be embedded on those terms, so an engineer rebuilds the dashboard by hand in Angular, against an API that does not exist yet — because building an API over that dataset is a second project with its own deployment, its own auth and its own on-call.
The expensive part was never the chart. It was the dataset, the API, and the embedding — three projects that each needed a team. datapipelines collapses the first two into something an agent can do in a session and a person can review in an afternoon: the dataset is a versioned pipeline across your databases, and the API is one release away. The third — the dashboard you embed — is planned, designed to be created by the same agent and fed by the same released pipelines.
Two columns, honestly
What ships today, and what is planned
Ships today Beside Tableau
- A governed dataset Tableau can read. Release a pipeline, publish it as a
GETendpoint under/api/x; the JSON it returns is what a Tableau web data connector reads — versioned, and released by a person. - Or land it where Tableau already looks. A pipeline node can write its result into a datasource — a Postgres table Tableau live-connects to — so the dataset refreshes when the pipeline runs and Tableau never learns a new connector.
- The prep step, as reviewable code. Joins across Postgres, MySQL, SQL Server, Oracle, SQLite and Parquet on S3 happen in a scratch database created per run — no warehouse between your sources and Tableau, no flow file nobody can diff.
- Access by path. An API key is bound to an endpoint prefix; a client, a partner or a Tableau workbook gets its endpoint and nothing else.
- A number you can trace. Every released version is immutable and audited; the dataset behind a chart is a version you can name.
Planned The parts Tableau does that we will
- Dashboards, created by your agent, that you embed in your own product — fed by released pipelines and APIs, filtered per viewer. The chart lives in your app, behind your login, showing each user their rows.
- Scheduling. Schedules in folders, fired exactly once across instances, every run a first-class execution — the nightly refresh without the nightly job.
- JSONata and JavaScript nodes for the shaping SQL is bad at — the nested response a dashboard wants, the pivot Prep did with a click.
Later, decided but not dated: scheduled extracts to your own bucket (Tableau reads Parquet natively), email alerts, and metrics defined once. The roadmap carries the same words.
Tableau Prep, or pipelines as code
Where a flow stops and a pipeline starts
A Prep flow is a diagram you edit; a pipeline here is a JSON document of SQL nodes with explicit dependencies, which happens to render as a diagram. The difference shows up on the second week: the pipeline is diffable in a pull request, versioned with a draft a reviewer can run before releasing, and writable by an AI agent that reads your schemas and catalogue statistics first. The flow is a file only one tool can open.
Both join across sources without a warehouse. Prep does it in memory on the machine running the flow; datapipelines does it in a scratch database created for the run, where each source node's rows are staged under a stable table name and the join is ordinary SQL any reviewer can read. When a source is slow, the node's query timeout and the SQL probe say which node and why — the agent fixes the shape from the plan, not from a spinner.
When the dataset is right, it is released — by a person, immutably — which is the property a Prep flow on a shared drive does not have. The full Prep comparison, including what Prep still does better and a five-step migration, has its own page: Tableau Prep, or pipelines as code.
What it looks like
The dataset behind the chart, as the reviewer sees it
| endpoint | serves | key reach |
|---|---|---|
GET /api/x/demo/top-company-by-borough?anchor_date=2025-01-01 |
demo/top_company_by_borough · v1 | /demo/** |
from the demo workspace — released by a human, served as this version forever
Asked before
Tableau questions, answered plainly
Can Tableau read what datapipelines produces?
Yes, two ways today. A released pipeline published as a GET endpoint returns JSON that Tableau's web data connector reads; or a pipeline writes its result to a datasource Tableau already connects to. Parquet on your own S3 bucket, read by Tableau natively, arrives with the lake write-back on the roadmap. The endpoint contract is docs/rest-api.md §19.
Is this a Tableau alternative?
Not today, and the page does not claim it. Tableau draws; datapipelines gets the data there — across Postgres, MySQL, SQL Server, Oracle, SQLite and S3, without a warehouse, authored by an agent and released by a person. Embedded dashboards created by your agent are planned; the roadmap page carries the status. What is versioned today is docs/versioning.md §3.
Why not just build the dashboard in Tableau?
Because the dashboard usually is not the expensive part — getting a trustworthy, joined, refreshed dataset into it is, and embedding the result in your own product is a second project. datapipelines makes the dataset a versioned pipeline an agent can author and an API you can call from your app today; the dashboards you embed are planned. Publishing is docs/rest-api.md §19.
Does datapipelines replace Tableau Prep?
For teams who would rather have their preparation as reviewable code than as a flow: a pipeline is a JSON document of SQL nodes with explicit dependencies, versioned, diffable, and runnable by an agent. It joins across engines in a scratch database the way Prep joins in memory, without a warehouse. The contract is docs/pipeline-contract.md §3.
Try the shipped half on your own databases
The demo stack joins Postgres, MySQL, SQLite and Parquet on S3 in one pipeline and publishes it as an endpoint. Point a Tableau web data connector at it and you have the pattern end to end, on a laptop, in an afternoon.