What we're 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 post gets updated as things land. Two items are done and marked below; the rest have not shipped.

A new runtime stack

Etlworks will move to Java 26 and Tomcat 11. The current stack has been stable for years and is now the thing blocking several other items on this list.

Hosted environments will be migrated for you. Self-hosted installations are free to stay where they are, and the current version will keep shipping alongside the new one for as long as customers need it. That is a commitment, not a plan to deprecate quietly in eighteen months.

CPython replaces Jython

Embedded Python will move from Jython to CPython. Jython has served us well and has been stuck on Python 2.7 the entire time, which means every script you write today is in a language that stopped receiving security fixes in 2020.

CPython brings Python 3 and the ecosystem that comes with it. JavaScript is unaffected and stays exactly as it is.

Built-in SSO

Shipped

SSO used to run through miniOrange. It worked, and it was also a third-party dependency sitting in your authentication path, which security reviews reliably flag.

Native SAML and OpenID Connect are now built in. The miniOrange path stays for anyone already using it.

Performance at scale

The ETL and CDC engines will get another optimization pass aimed at large workloads rather than benchmark numbers. The target is the shape of problem where a single table dominates a run while everything else waits, and where adding threads helps less than it should.

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.

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.

dbt integration

Shipped

Customers running dbt wanted Etlworks to load the raw data and trigger the transformation, which meant the two systems scheduling around each other.

dbt Core now runs as a native flow type against a warehouse connection you already have, with the project pinned to a Git commit and artifacts landing in execution history. There is a separate flow for triggering dbt Platform jobs. Details are on the dbt integration page.

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 the agent 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.

What this is not

This is not a commitment document. Items move, and occasionally one turns out to be the wrong idea and gets dropped.

If a specific item matters more to you than the rest, say so at product@etlworks.com. That address reaches the people who decide the order, and customer pressure is the main thing that changes it.