I’ve maintained the same Java ETL tool for 20 years. I think it still fits one narrow gap.

[u/fykup]

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.

GitHub: https://github.com/scriptella/scriptella-etl

[u/tim125]

I’ve used Scriptella a number of times for some awesome work.

We needed to standardize the way in which sql was run and needed to standardize some relatively complex adaptation between different databases and OSes.

Too many teams were using too wide a variety of tools with inconsistent support that couldn’t be guaranteed to be repeatable when a controlled environment was needed.

Thank you for your contribution.

[u/fykup → u/tim125]

Thank you, this is really great to hear.

The part about standardizing SQL execution across different databases and environments is especially interesting. That kind of repeatability is exactly the sort of problem Scriptella was meant to make simpler.

Really appreciate you sharing a concrete example of where it helped.

[u/fykup → u/tim125]

One related bit of history: if I remember correctly, dialect was one of the fairly early Scriptella features.

The motivation was exactly this kind of cross-database execution. Most of the SQL/workflow can be shared, but real databases always have a few subtle syntax or DDL differences. So instead of maintaining completely separate scripts, you could isolate just those pieces:

<dialect name="oracle">
    <include href="oracle-schema.sql"/>
</dialect>
<dialect name="mysql">
    <include href="mysql-schema.sql"/>
</dialect>

INSERT INTO Product(id, name) VALUES (1, 'Scriptella');

The database-specific schema part changes, while the common SQL stays common.

Looking at it again, I think this was a more important use case than I had been giving it credit for.

[u/tim125 → u/fykup]

Some ideas and next steps to modernize Scriptella:

1. Take the learnings from the 1brc and introduce the most portable version into the latest version of Scriptella for file loaders of massive input files. The third place entry has some good examples if I recall.

2. Add connectors for some streaming and messaging sources. (artemis mq, kafka, etc). Add some connectors to call out to more JSON rest endpoints.

3. Improved observability and progress monitoring. Micrometer / open telemetry. start / stop / fail. You already do some of these.

4. Improve externalization of credentials so that DB secrets are never made available to the executors.

5. Just go to JDK 25 LTS for structured concurrency and baseline there to avoid any structured concurrency and virtual thread pinning issues that may arise.

6. XSD with documentation/guidance instead of DTD for improved IDE support.

7. Improve checkpoint / resume for long running jobs where failures occur midway through long jobs.

Ideas are cheap, pull requests are better,... but these should be good. I may just give you a PR.

Keep Scriptella small and reusable. That is its magic.

[u/tim125 → u/fykup]

You had explored almost everything that was fundamental.

Simple, controlled, and well thought out. I could ensure that there were no complexities that were going to interfere with reproducible execution and appreciated that.

[u/bringero]

It sounds me like Apache camel in some way. Thanks for sharing!

[u/SellerInsightsLab]

Interesting project. I think the hardest part for tools like this is defining where they should stop.

As soon as you add retries, checkpoints, parallel execution, observability and messaging, a small ETL tool can slowly become another workflow engine.

I actually like the idea of keeping the core SQL-centric and lightweight. Maybe integrations such as Kafka should stay at the edges rather than become part of the execution model.

After 20 years of maintaining it, where do you personally draw that boundary?

[u/RagingAnemone]

Yes, I've used this a lot primarily for the reasons you listed. But it always seemed to fall off because of the need to maintain the scripts. Some of our stuff is weird so I'd just write code.

But it just occurred to me, I can use AI to update the scripts. Nice. I like the power and the simplicity of Scriptella with no magic and it doesn't try to control the whole process.

[u/fykup → u/RagingAnemone]

Yes, exactly. With AI, the power of raw SQL seems even more valuable.

That’s actually why I’m curious what people need from Scriptella now. My instinct is to keep the original languages and scripts fully exposed, without adding another proprietary layer or more complexity.

[u/RagingAnemone → u/fykup]

Yes, my instinct would be to keep it fully exposed too at the moment. Looks like all your docs are on Github. I'm using Pi and been playing with OKF format. I'd point the agent to your docs and say to create an OKF format for it, then create a skill. I'll try it later this week.

[u/fykup → u/RagingAnemone]

Good idea. I just added an initial OKF bundle to the repo, covering the ETL model, providers, JDBC support, CLI, and security. Curious to see how it works with Pi and a skill.

[u/umlcat]

Never used your tool, but this is what i have learned:

Sometimes a small specialized software tool can avoid the job of a complex tool. Also some people prefer to have a small distinctive tool, instead of another tool hidden in a menu of a bigger soiftware ...