Roadmap
What we are building next.
We do not put dates on roadmap items, because any date we gave you would be wrong. What follows is direction and reasoning. This page is kept current; when something ships it moves off the list and into a release post.
In progress
Schema drift: ALTER and DROP.
ETL and CDC flows already handle added columns and added tables. The other half is missing.
Altering a column and dropping a column are next. A type widening upstream should not need someone to intervene, and neither should a column disappearing. The destination already gets read before every write, which is where this work goes.
Next
Operating the AI agents you already run.
Teams are running several AI agents from different vendors, each with its own console and its own idea of what a run is. Knowing whether they did their work falls back on people, spreadsheets and a chain of Zapier steps. That is the same problem four disconnected ETL tools created, in a new place.
We are building a registry for those agents and an evidence model underneath it. You register an agent against a connection you already have, so no credential moves. Health is calculated from evidence rather than guessed, which means it can tell an agent that is idle apart from one that has gone silent when work was expected, apart from one whose token expired. Control actions, where a vendor supports them, run through the same approval and audit path as everything else in the platform, and the events land next to your execution history so one correlation ID covers the pipeline and the agent that triggered it.
This follows the hosted migration to 10.0. Nothing here needs an LLM: the registry, the health calculation and the approval ledger are ordinary deterministic machinery.
What it is not. Not a gateway that proxies your models. Not a scanner that finds agents by itself. Not a promise to control a closed vendor's agent: what can be observed and what can be acted on depends on the API each vendor actually exposes, and we will name which operations each adapter supports rather than implying all of them. An agent we cannot get evidence from will read as unknown, not as healthy.
One naming note, because the word is overloaded here. This is about AI agents from vendors such as Salesforce Agentforce, and about Simba, our own AI agent. It is not the Integration Agent, the Etlworks worker you install on your own hardware, which keeps its own screen and lifecycle.
Next
Official Kubernetes support.
Plenty of customers already run Etlworks on Kubernetes. What they do not have is a supported path: charts we maintain, a documented multi-node topology, and behavior we test rather than infer.
That will become official. The goal is that a multi-node deployment stops being a project. The 10.0.0 Agent generation, with its own command line and a plain Docker lifecycle, is the groundwork for it.
Next
Data lineage and a data catalog.
Execution history already records what ran, against which connection, and what it touched, and dbt flows surface node-level lineage from the artifacts they capture. What is missing is the view across all of it.
End-to-end lineage is next: one graph spanning every flow type rather than dbt alone, so a column in a destination can be traced back through the transformations to the source that produced it. On top of that, a catalog of the datasets, connections and schemas the platform already knows about, searchable, and answerable by Simba the same way execution history is today.
Most of the metadata exists already. The work is making it queryable and keeping it correct as flows change.
Recently shipped
Off the list.
Five items that were on this roadmap have shipped. Two of them shipped differently from the way we described them, which is covered in the scorecard.
pipWhat this is not
Not a commitment document.
Items move, and occasionally one turns out to be the wrong idea and gets dropped. Nothing here carries a date, and an item being on this page does not mean it is in the next release.
If a specific item matters more to you than the rest, say so. That address reaches the people who decide the order, and customer pressure is the main thing that changes it.
Need something that is not here?
Tell us what is blocking you. Feature requests are read by the people who set the order, and what customers ask for is what moves.