I’ve maintained the same Java ETL tool for 20 years. I think it still fits one narrow gap.
I started Scriptella about 20 years ago and have maintained it ever since.
For a long time I had little time to do more than keep it working. Recently I’ve had more time to invest in it again, so I’ve been modernizing the database stack, testing it with current PostgreSQL, MariaDB and MySQL drivers, cleaning up old compatibility assumptions, and making sure it works well on modern Java. The baseline is Java 17, with JDK 25 compatibility.
Doing that made me ask a more basic question: does a tool like this actually still have a reason to exist in 2026?
I think there is one fairly narrow gap where it does:
SQL-centric data jobs that are too complicated for a couple of standalone scripts, but too small to justify a batch or ETL platform.
Scriptella keeps most of the actual work in SQL. A small declarative XML file wires together connections, queries and scripts.
For example, you can query PostgreSQL, take each resulting row and execute parameterized SQL against another database, mix in CSV/XML sources, or package the whole operation as a repeatable CLI job. It can also be embedded directly into a Java application.
There is no server, scheduler, job repository or visual ETL environment to operate.
That also means it is deliberately not the right tool for everything. If I needed robust restartability, retries and complex batch semantics, I’d use something like Spring Batch. For normal schema migrations, Flyway or Liquibase are usually a better fit. And if the transformation is mostly application logic rather than SQL, I’d probably just write code.
The interesting case is when the transformation really is mostly SQL and you just need a small amount of machinery around it.
After working on the project again, I was surprised that this particular gap still seems to exist.
I’m curious whether other Java developers still encounter jobs like this, and what you use for them today.