Quem procura este comparativo quase nunca está escolhendo do zero.
Já tem Pentaho instalado, rodando há anos, com dezenas de rotinas montadas por alguém que talvez nem trabalhe mais na empresa. A pergunta real não é qual ferramenta é melhor. É se vale continuar mantendo aquilo.
O problema é que essa conta raramente é feita. Ela não aparece na comparação de recursos, porque não é sobre recurso: é sobre quantas horas por mês alguém gasta para a ferramenta continuar de pé.
Neste artigo, comparamos os dois desenhos pelo que cada um exige do time — servidor, transformação, origem nova e rotina que quebra —, sempre a partir do material público do Pentaho. E dizemos em que casos trocar não compensa.
O servidor que deixa de existir
Comece pela diferença que aparece todo mês, e não no dia da escolha.
O Pentaho roda num servidor que alguém instala e mantém. Versão de Java, memória, disco, atualização, cópia de segurança, repositório de pé para as rotinas agendadas rodarem. É trabalho de infraestrutura, e em time pequeno quem faz é o analista de BI.
No Januss não há servidor para operar. O agendamento vem junto, com onze frequências e cron personalizado, e aviso por e-mail na falha e na recuperação. Depois de três falhas seguidas o pipeline se desliga sozinho, em vez de insistir em silêncio queimando franquia.
E quando o dado não pode sair da rede? Aí entra o Runner, instalado por um comando e atualizado sozinho, com uma única conexão de saída na porta 443 e nenhuma regra de firewall de entrada. Continua sem servidor de aplicação para operar: o que roda na sua rede é um executor, não uma plataforma.
A diferença não é de recurso. É de quem acorda quando aquilo cai.
Onde o dado é transformado
A segunda diferença é arquitetural, e explica o que acontece quando o volume cresce.
Nas transformações do Pentaho, os registros fluem pela própria ferramenta: saem da origem, passam pelo motor, e só então chegam ao destino. Isso dá controle fino sobre cada passo — e faz da máquina onde a ferramenta roda o ponto por onde o volume inteiro precisa passar.
No Januss a transformação é SQL executado dentro do banco de destino, com dependência entre etapas e reprocessamento só do escopo que mudou. O dado não trafega por um motor intermediário: quem processa é o banco, que já foi feito para isso.
A troca tem um preço, e é justo dizer qual é. O que não couber em SQL não cabe no Januss. Não há editor visual de fluxo com centenas de passos prontos, e não há extensão em Java para o caso que nenhum passo atende. O Pentaho tem as duas coisas, e para quem as usa de verdade elas decidem sozinhas.
Os dois desenhos, lado a lado
A tabela compara o desenho de cada um. Ela não dá nota a ninguém: descreve como cada ferramenta foi construída, e é a partir daí que a escolha fica possível.
Três linhas concentram a decisão de quem já tem o Pentaho de pé. Onde a ferramenta roda, porque é a linha que aparece na conta todo mês. Onde a transformação acontece, porque é ela que decide o que acontece quando o volume cresce. E o conector de API, porque é o trecho em que cada origem nova custa dias.
As duas últimas linhas vão na direção contrária, e é bom que fiquem visíveis. O Pentaho cobre um território maior — relatório, análise, catálogo — e se estende com programação para o caso que nenhum passo pronto atende. O Januss não faz nem uma coisa nem outra, e não pretende fazer.
| Januss | Pentaho | |
|---|---|---|
| Onde roda | Nuvem gerenciada, ou Runner na sua rede quando o dado não pode sair | Servidor que você instala e mantém |
| Onde a transformação acontece | Em SQL, dentro do banco de destino | No motor da própria ferramenta, antes de escrever |
| Conector de API | A IA escreve o conector a partir da documentação, e ele só é salvo depois de uma chamada real que leu o dado | Passo de chamada HTTP, com autenticação e paginação montadas por você |
| Captura de mudanças por log | Leitura do log em cinco bancos, em todos os planos, inclusive o de entrada | Existe no Pentaho CDC, com Debezium — produto à parte, em disponibilidade limitada para avaliação |
| Agendamento | Vem junto: onze frequências de 5 min a 24 h, mais cron, com prévia antes de salvar | Agendador do repositório, ou cron chamando as ferramentas de linha de comando |
| Testes de qualidade | Declarados por coluna, com severidade: podem parar a execução e bloquear o downstream | Passos de validação, montados dentro de cada rotina |
| Formato regional | Treze regras de conversão por coluna, com oito formatos regionais | Passos de formatação, configurados rotina por rotina |
| Escopo do produto | Só integração e transformação | Integração, análise, relatório, catálogo e otimização de dados |
| Como se estende | SQL, e nada além disso | Centenas de passos prontos, mais extensão em Java |
As linhas descrevem o desenho de cada ferramenta, não uma nota de qualidade. O material público do Pentaho foi consultado em 27 de agosto de 2026.
Origem nova: API e captura de mudanças
É aqui que o desenho antigo cobra mais caro, porque as origens de hoje não são as de quinze anos atrás.
No Pentaho existe o passo de chamada HTTP, e ele funciona. O que é montado à mão, rotina por rotina, é o resto: autenticação que se renova, resultado partido em páginas com a regra daquela API, campo dentro de campo. E remontado quando a API muda.
No Januss a IA escreve o conector a partir da especificação OpenAPI ou da documentação que você colar. Ela resolve autenticação e paginação, e o conector só é salvo depois de uma chamada real que conseguiu ler o dado. Depois disso ele é determinístico: a extração roda sempre igual, sem IA no caminho do dado.
Na captura de mudanças, os dois leem o log. O Pentaho tem o Pentaho CDC, construído sobre o PDI e sobre o Debezium, que captura inserção, atualização e exclusão direto do log de transações. O material público o descreve como produto à parte, em disponibilidade limitada para avaliação, e não lista os bancos cobertos.
No Januss a leitura de log é do produto, em PostgreSQL, MySQL, SQL Server, Oracle e MongoDB, em todos os planos. Antes da primeira carga a plataforma confere os pré-requisitos na origem e, quando falta algum, mostra o comando que resolve — incluindo o caminho diferente do Amazon RDS.
O que custa manter a rotina viva
O custo que decide não é o da licença nem o da assinatura. É o de manter em pé o que já existe.
Rotina montada em editor visual guarda a lógica no desenho, e o desenho é lido por quem o fez. Quando essa pessoa sai, o que fica é uma tela com passos que alguém precisa abrir um a um para entender.
Exemplo prático
Uma indústria mantém quarenta rotinas montadas ao longo de seis anos. O analista que as construiu saiu em 2023. Hoje, quando uma quebra, o time abre a rotina no editor e tenta reconstruir o que aquele passo faz. Ninguém documentou. A ferramenta não é o problema: o conhecimento estava nela, e não estava escrito em lugar nenhum.
O SQL não resolve isso sozinho, mas muda o material. Uma transformação em SQL é lida, revisada e corrigida por qualquer pessoa que saiba SQL, e o log de execução do Januss mostra o comando que rodou, o watermark e o antes e depois.
O que se perde numa saída é conhecimento. O que fica é o que dá para ler.
O que mudou na licença da edição comunitária
Este é o ponto que mais mudou desde a última vez que muita gente olhou, e o que mais pesa em orçamento.
Até a versão 9.5, a edição comunitária do Pentaho vinha sob a licença Apache 2.0, que permite uso comercial livre. A partir da versão 10.2, ela passou para a Business Source License, que impõe restrições ao uso comercial por um período.
Na prática, quem apoia a decisão no custo de licença zero precisa ler a licença da versão que pretende rodar, e não a da versão que instalou anos atrás. As versões antigas seguem com a licença que tinham; as novas, não.
Há um segundo prazo correndo junto, e ele é de suporte, não de licença. O ciclo de vida publicado tira o suporte das versões antigas em datas fixas: a 9.3 saiu de suporte em julho de 2026, e a versão corrente é a 11, de maio de 2026. Instalação que ficou parada em versão antiga acumula as duas coisas: sem suporte e distante do caminho de atualização.
Vale a ressalva de sempre: boa parte do material sobre preço de Pentaho na internet foi escrita por concorrentes diretos, que têm interesse em pintar a conta como pior do que é. Nenhum número de licença aparece neste texto por esse motivo. Peça a cotação direto.
Custo zero de licença é um argumento. Ele só precisa ser o argumento da versão certa.
Como decidir
As rotinas estão estáveis e alguém no time as domina? Então trocar por trocar é despesa sem retorno. Ferramenta que roda e tem dono não é problema a resolver.
A extensão em Java é usada de verdade, ou apenas possível? Se há passo de código rodando em produção, ou uma origem que só se resolve programando, o Pentaho atende o que o Januss não atende. É a pergunta que decide sozinha.
Você depende da camada de relatório e catálogo da mesma ferramenta? O Januss entrega o dado no destino e para por aí. Se o relatório vive na mesma plataforma hoje, trocar significa escolher outra ferramenta para isso.
Quantas horas por mês o time gasta mantendo a ferramenta? Somando operação do servidor, rotina que quebrou e origem nova para montar. Se o número competir com o tempo de usar o dado, o custo mudou de lugar.
A troca compensa quando manter a ferramenta passou a competir com o trabalho que ela deveria liberar.
Onde o Januss entra
O Januss foi construído para o time que sabe SQL, responde pelo número e não quer operar servidor de aplicação.
Extração com conector escrito pela IA e leitura de log em cinco bancos. Transformação em SQL dentro do destino, com reprocessamento só do escopo que mudou. Testes declarados que interrompem a carga antes de o dado errado chegar. Agendamento, alerta por e-mail e desligamento automático depois de três falhas seguidas. Cobrança por linha escrita no destino, em real, com teto de fatura por plano.
Se você precisa de extensão em Java, de editor visual com centenas de passos prontos ou da camada de relatório na mesma ferramenta, o Pentaho continua atendendo o que o Januss não atende. Essa parte não mudou.
O que mudou é o resto da conta: o servidor, a origem nova, a rotina órfã e a licença da próxima versão.
Quer testar com uma origem sua antes de decidir? São 14 dias de teste, sem cartão de crédito: criar seu ambiente.
Crie seu workspace em minutos.
Aponte para a sua origem e veja o dado chegando ao banco no mesmo dia.