The MCP server
An agent authors, runs, inspects and iterates pipelines through 61 tools over Streamable HTTP, with your own key and an audit row per call. The tool list.
What ships, and what is planned
Roadmap
Three bands, and the words mean what they say. Shipped is in the current release and specified in the packaged docs. Planned describes features being designed or developed. Later describes longer-term direction. Planned features have no announced release date.
Last updated 2026-10-25
Shipped
In the current release
Eight engines, one pipeline
Postgres, Oracle, SQL Server, MySQL, H2, DuckDB, SQLite and dp-lake, plus Parquet and Iceberg on S3, read in place. Each node runs where its data lives.
Joins without a warehouse
Every run gets a scratch database that exists for exactly that run; sources are staged into it and joined there. How federated query works.
Draft → release, by a person
Agents leave drafts. A human releases; a release is immutable; a discarded release can be restored. Every verb is audited with the surface it came through.
Published endpoints
A released pipeline served as a versioned GET under your own /api namespace, parameters bound from the query string, keys scoped to a path prefix. SQL to API.
Agent probes
Catalogue statistics and indexes per table, and a bounded sql_probe that returns rows, wall time and the plan, so an agent fixes a slow shape from evidence.
Scheduler
A schedule runs one pipeline at a five-field cron pattern's times in an IANA time zone, with a preview of the next runs, pause, resume, run now and a history of every run. People manage schedules in the application; agents do not. Pipeline scheduling.
Schedule notices by mail
When scheduler mail is enabled and a schedule has recipients, selected run events queue a notice. Failure, unknown and blocked events default on; start and success are opt-in.
Dashboards
Charts, tables and KPI cards over pinned, released pipelines, with filters from a reusable parameter set. An agent drafts them, a person releases them, and your product can embed them through its own backend. SQL dashboards.
JSONata and JavaScript nodes
A SCRIPT node runs a versioned JSONata or JavaScript template over staged tables, with no handle to the network or the filesystem. JavaScript is not Node: it runs in an isolate the Docker image includes, and a server without it keeps JSONata.
Public beta
Known limitations
At production standard today: the pipeline lifecycle, meaning draft, human release and immutable versions, API keys and the role-based permission catalog, purge, discard and restore, and promotion between deployments. What follows is scope, not warning. Each line is a roadmap row, linked, with where it lands on this page.
- No in-browser pipeline or template authoring without an agent: the editors preview, execute, release and discard; authoring is MCP-first today. docs/ROADMAP.md §2.2
- Schedules run pipelines only: report delivery and condition alerts remain later, and schedule routes take a signed-in session. docs/scheduler.md §9
- No report generation yet: dashboards ship; scheduled reports, PDF export and condition alerts do not. docs/ROADMAP.md §2.2
- A dashboard's read-only rule is declared: sources are admitted by their nodes' declared types, not by a read-only database connection; enforcing it at the connection is tracked separately. docs/dashboards.md §5.1
- No report or query-result mail yet: condition alerts, report delivery and email output targets remain future work; schedule run notices are available. docs/ROADMAP.md §2.2
- No audit-log screen yet: the audit log is written on every call and read by SQL today; the filter screen is on the backlog. docs/ROADMAP.md §2.2
- The v2 band is design-stage: nested types, conditional execution, per-node retries, SAML, MFA and the rest of docs/ROADMAP.md §3 are decided direction, not shipped product.
Found something that is not on this list? Report what breaks. The bug form asks for the version and the correlation id, so a fix starts from evidence.
Planned
Designed, in progress
Schedules for your own backend
- A management credential, so a backend can create schedules for its own customers.
- Background one-time runs of a pipeline, outside any schedule.
Report generation
- A document, not a chart, rendered over a released pipeline's result and delivered by email first.
- The design is pending.
Later · decided, not scheduled
The next layer
Scheduled extracts to your lake
- A scheduled pipeline materialises to Parquet on your own bucket; DuckDB, and Tableau too, read it back at interactive speed.
- The lake you already own becomes the extract store, with no second copy of the data anywhere else.
Email alerts
- A scheduled pipeline, a condition, an email. Nothing else is promised until it exists.
Metrics
- Measures defined once over a pipeline's output and read by dashboards and endpoints alike.
What is deliberately not on this page: a hosted plan, native mobile apps, a story-points feature, and Slack. The first two are decisions for after the planned band ships; the last two are not planned.
If you came here from Tableau
What this means beside Tableau
Today datapipelines gets a governed dataset into Tableau, as an API or into a database it reads, a schedule can rerun the pipeline behind it, and its own SQL dashboards can sit in your product beside Tableau. Later, extracts on your own bucket. The Tableau page keeps the two columns, ships today and roadmap, side by side.