Beside Tableau, not instead of it, not 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 and after the drawing. Before it: getting a trustworthy, joined, refreshed dataset in front of Tableau from four databases and a bucket. 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, and SQL dashboards your backend embeds now cover much of the second. Scheduled extracts and alerts are 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, now ships too: the same agent drafts it, the same released pipelines feed it, and your backend shows it inside your product.
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 your own/apinamespace; 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.
- Dashboards your product embeds. Drafted by your agent over released pipelines, released by a person, shown through your own backend, which holds the key and decides each viewer's filter values.
- Schedules. A pipeline runs on a cron pattern in its own time zone, 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.
Planned The parts Tableau does that we will
- Scheduled extracts to your own bucket, which Tableau reads natively: a schedule runs a pipeline today, but it does not write an extract file yet.
- Mail and alerts. Schedule run notices are available when scheduler mail is enabled and recipients are configured; alerts on a SQL condition and report delivery are later.
- Metrics defined once, shared by every dashboard that reads them.
Decided but not dated. The roadmap and the extracts, alerts and dashboards page carry 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/demo/v1/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. Its own SQL dashboards are drafted by an agent and laid out in a document, with no drag-and-drop editor (docs/dashboards.md §2.2). 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, and a dashboard over it can be embedded through your own backend (docs/dashboards.md §6.5). 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.