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 GET endpoint 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

The pipeline an agent authored across four sources, in the editor, with the result dock open.
SOURCES STAGING · H2 IN MEMORY ANSWER sample-lake · Parquet on S3 hvfhv_zone_day · 377k rows sample-reference · SQLite zones · 265 rows calculator · trailing_periods anchor 2025-01-01 → Q4 2024 stage_company_zone 523 rows · 482 ms stage_zones 263 rows · 204 ms answer 6 rows · caller DRAFT demo/top_company_by_borough · v1 · awaiting a human release · then GET /api/x/demo/…
The published endpoint in the API console — the URL Tableau reads, the key bound to its path.
workspace: demo · API
endpointserveskey 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.