All posts

What we're building next

A new runtime stack, CPython replacing Jython, built-in SSO, official Kubernetes support, and dbt. Nothing here has shipped yet.

Nothing in this post has shipped. We do not put dates on roadmap items, because any date we gave you would be wrong. What follows is direction and reasoning.

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

SSO today runs through miniOrange, and it works. It is also a third-party dependency sitting in your authentication path, which security reviews reliably flag.

We will add native SSO alongside it. 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

Everyone integrates with dbt. We will too.

Customers running dbt want Etlworks to load the raw data and trigger the transformation, which today means the two systems scheduling around each other. Making it a first-class step will remove that.

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.

Try it on your own data.

14 days, no card. Point Etlworks at a real source and see what it does.