Anyone looking for this comparison is almost never choosing from scratch.
They already have Pentaho installed, running for years, with dozens of routines built by someone who may no longer work at the company. The real question is not which tool is better. It is whether keeping that going is still worth it.
The problem is that this sum is rarely done. It does not show up in a feature comparison, because it is not about features: it is about how many hours a month someone spends keeping the tool standing.
In this article we compare the two designs by what each one asks of the team — server, transformation, new source and the routine that breaks —, always from Pentaho’s public material. And we say when switching does not pay off.
The server that stops existing
Start with the difference that shows up every month, not on the day you choose.
Pentaho runs on a server somebody installs and maintains. Java version, memory, disk, upgrades, backups, a repository kept up so the scheduled routines can run. That is infrastructure work, and on a small team the BI analyst is the one doing it.
In Januss there is no server to operate. Scheduling comes with it, with eleven frequencies and custom cron, and email alerts on failure and on recovery. After three failures in a row the pipeline shuts itself down, instead of running on quietly and burning through the allowance.
And when the data cannot leave the network? That is what the Runner is for, installed with a single command and updated on its own, with one outbound connection on port 443 and no inbound firewall rule. There is still no application server to operate: what runs on your network is an executor, not a platform.
The difference is not a feature. It is who wakes up when that thing goes down.
Where the data is transformed
The second difference is architectural, and it explains what happens as volume grows.
In Pentaho transformations, records flow through the tool itself: they leave the source, pass through the engine, and only then reach the destination. That gives fine control over every step — and makes the machine the tool runs on the point the whole volume has to cross.
In Januss the transformation is SQL running inside the destination database, with dependencies between steps and reprocessing limited to the scope that changed. The data does not travel through an intermediate engine: the database does the processing, and it was built for that.
The trade has a price, and it is fair to say what it is. Whatever does not fit in SQL does not fit in Januss. There is no visual flow editor with hundreds of ready-made steps, and no Java extension for the case no step covers. Pentaho has both, and for anyone who genuinely uses them they decide on their own.
The two designs, side by side
The table compares how each one is designed. It scores nobody: it describes how each tool was built, and that is what makes the choice possible.
Three rows carry the decision for anyone who already has Pentaho running. Where the tool runs, because that is the row that shows up in the sum every month. Where the transformation happens, because it decides what occurs as volume grows. And the API connector, because that is the stretch where every new source costs days.
The last two rows point the other way, and it is good that they stay visible. Pentaho covers a wider territory — reporting, analytics, catalogue — and extends with code for the case no ready-made step covers. Januss does neither, and does not intend to.
| Januss | Pentaho | |
|---|---|---|
| Where it runs | Managed cloud, or a Runner on your network when the data cannot leave | A server you install and maintain |
| Where the transformation happens | In SQL, inside the destination database | In the tool’s own engine, before writing |
| API connector | The AI writes the connector from the documentation, and it is only saved after a real call that read the data | An HTTP call step, with authentication and pagination built by you |
| Log-based change capture | Log reading on five databases, on every plan, including the entry one | Available in Pentaho CDC, with Debezium — a separate product, in limited availability for evaluation |
| Scheduling | Comes with it: eleven frequencies from 5 min to 24 h, plus cron, previewed before saving | The repository scheduler, or cron calling the command line tools |
| Quality tests | Declared per column, with severity: they can stop the run and block downstream steps | Validation steps, built inside each routine |
| Regional formats | Thirteen conversion rules per column, with eight regional formats | Formatting steps, configured routine by routine |
| Product scope | Integration and transformation only | Integration, analytics, reporting, catalogue and data optimisation |
| How it extends | SQL, and nothing beyond it | Hundreds of ready-made steps, plus Java extensions |
The rows describe how each tool is designed, not a quality score. Pentaho’s public material was consulted on 27 August 2026.
A new source: APIs and change capture
This is where the older design charges the most, because today’s sources are not the ones from fifteen years ago.
Pentaho has an HTTP call step, and it works. What gets built by hand, routine by routine, is everything else: authentication that refreshes itself, results split into pages with that API’s own rule, fields inside fields. And rebuilt when the API changes.
In Januss the AI writes the connector from the OpenAPI spec or from the documentation you paste in. It works out authentication and pagination, and the connector is only saved after a real call that managed to read the data. After that it is deterministic: extraction runs the same way every time, with no AI in the path of the data.
On change capture, both read the log. Pentaho has Pentaho CDC, built on PDI and on Debezium, capturing inserts, updates and deletes straight from the transaction log. The public material describes it as a separate product, in limited availability for evaluation, and does not list the databases it covers.
In Januss, log reading is part of the product, on PostgreSQL, MySQL, SQL Server, Oracle and MongoDB, on every plan. Before the first load the platform checks the prerequisites on the source and, when one is missing, shows the command that fixes it — including the different path for Amazon RDS.
What it costs to keep a routine alive
The cost that decides is not the licence or the subscription. It is keeping what already exists standing.
A routine built in a visual editor keeps its logic in the drawing, and the drawing is read by whoever made it. When that person leaves, what remains is a canvas of steps somebody has to open one by one to understand.
A concrete example
A manufacturer keeps forty routines built over six years. The analyst who built them left in 2023. Today, when one breaks, the team opens the routine in the editor and tries to reconstruct what that step does. Nobody documented it. The tool is not the problem: the knowledge lived inside it, and was written down nowhere.
SQL does not solve that on its own, but it changes the material. A transformation in SQL is read, reviewed and fixed by anyone who knows SQL, and the Januss run log shows the command that ran, the watermark and the before and after.
A departure takes the knowledge with it. What stays is whatever can be read without the person who wrote it.
What changed in the community edition licence
This is the point that changed most since many people last looked, and the one that weighs most on a budget.
Up to version 9.5, the Pentaho community edition came under the Apache 2.0 licence, which allows free commercial use. From version 10.2 onwards it moved to the Business Source License, which places restrictions on commercial use for a period.
In practice, anyone resting the decision on zero licence cost has to read the licence of the version they intend to run, not the one they installed years ago. Older versions keep the licence they had; newer ones do not.
There is a second clock running alongside it, and it is about support, not licensing. The published lifecycle drops support for older versions on fixed dates: 9.3 went out of support in July 2026, and the current version is 11, from May 2026. An installation left on an old version accumulates both problems: no support, and a long way from the upgrade path.
The usual caveat applies: much of the material about Pentaho pricing online was written by direct competitors, who have an interest in painting the bill as worse than it is. No licence figure appears in this text for that reason. Ask for the quote directly.
Zero licence cost is an argument. It just has to be the argument for the right version.
How to decide
Are the routines stable, and does someone on the team know them well? Then switching for the sake of switching is spending with no return. A tool that runs and has an owner is not a problem to solve.
Is the Java extension genuinely used, or merely possible? If there is code running in production, or a source that can only be solved by programming, Pentaho covers what Januss does not. That question decides on its own.
Do you depend on the reporting and catalogue layer of the same tool? Januss delivers the data to the destination and stops there. If reporting lives on the same platform today, switching means choosing another tool for it.
How many hours a month does the team spend maintaining the tool? Counting server operation, the routine that broke and the new source to build. If that number competes with the time spent using the data, the cost has moved.
Switching pays off when keeping the tool has started to compete with the work it was supposed to free up.
Where Januss comes in
Januss was built for the team that knows SQL, answers for the number and does not want to operate an application server.
Extraction with an AI-written connector and log reading on five databases. Transformation in SQL inside the destination, reprocessing only the scope that changed. Declared tests that stop the load before wrong data arrives. Scheduling, email alerts and automatic shutdown after three failures in a row. Billing per row written to the destination, with an invoice cap on every plan.
If you need Java extensions, a visual editor with hundreds of ready-made steps or the reporting layer in the same tool, Pentaho still covers what Januss does not. That part has not changed.
What changed is the rest of the sum: the server, the new source, the orphaned routine and the licence of the next version.
Want to try it with a source of your own first? The 14-day trial does not ask for a card: create your workspace.
Create your workspace in minutes.
Point at your source and watch the data reach the database the same day.