Toda avaliação de ferramenta de integração começa pela lista de conectores. É o critério mais fácil de comparar: você abre as duas páginas, procura os seus sistemas e conta quantos aparecem em cada uma.
Só que a lista é o piso. Fivetran e Januss leem o log de transações dos bancos mais comuns, transformam em SQL dentro do destino e agendam a carga. Nesse nível, os dois resolvem o mesmo problema.
O problema é que a decisão real não está aí. Ela está em três perguntas que raramente cabem numa demonstração: onde esse dado é processado, o que você consegue mudar nele durante a carga e o que a fatura faz quando o volume cresce.
Neste artigo comparamos os dois produtos ponto a ponto, sempre a partir do material público do Fivetran. Cinco eixos: onde o dado roda, de onde ele vem, o que dá para fazer com ele na carga, o que o histórico custa e como cada plataforma conta o que cobra.
Onde o seu dado é processado
Comece por aqui, porque é o eixo que mais muda de resposta conforme o plano — e o que menos aparece numa demonstração.
Quando o dado não pode sair da sua rede, o Januss instala o Runner dentro dela. Ele fala com a plataforma por uma única conexão de saída na porta 443, sem regra de firewall de entrada. Extração, transformação e carga acontecem ali dentro, e o dado não passa pela nuvem.
Isso não é um item de plano superior. É como o produto funciona, do plano de entrada em diante. Quando a execução é na nuvem, a região é escolha da conta: Brasil ou Estados Unidos.
As credenciais seguem a mesma lógica. Elas são cifradas no seu navegador, antes de saírem da sua máquina, e a plataforma guarda só o pacote cifrado — quem abre é o executor, no instante da execução.
O Fivetran tem um modelo equivalente para a primeira parte, o Hybrid Deployment: um agente na sua rede, com comunicação de saída. Segundo a documentação, “apenas metadados (incluindo informação de MAR) e logs são enviados ao Fivetran”. A mesma página diz também que “você precisa ter um plano Enterprise ou Business Critical para usar o modelo Hybrid Deployment”.
Sobre região, o material público lista doze geografias de processamento: Estados Unidos, Canadá, União Europeia, Reino Unido, Austrália, Cingapura, Índia, Japão, Coreia do Sul, Indonésia, Oriente Médio e Suíça. O Brasil não está na lista. Escolher o provedor de nuvem exige plano Enterprise; escolher a região específica, Business Critical.
Se o seu jurídico já escreveu residência de dado em contrato, esse eixo decide sozinho.
Os dois, lado a lado
Antes de destrinchar, o retrato inteiro:
| Januss | Fivetran | |
|---|---|---|
| Onde o dado é processado | Nuvem no Brasil ou nos Estados Unidos, ou Runner dentro da sua rede — em qualquer plano | Doze geografias, sem Brasil; execução na sua rede exige Enterprise ou Business Critical |
| Origens | Cinco bancos, MongoDB, planilhas e arquivos — e qualquer API REST que você apontar | Mais de 700 conectores prontos |
| API fora do catálogo | Conector escrito pela IA a partir da documentação, validado por chamada real antes de salvar | Connector SDK: você escreve connector.py em Python, testa local e publica com fivetran deploy |
| Modo de sincronização | Carga completa, incremental, espelhamento ou histórico versionado, escolhidos tabela a tabela | Modo histórico “disponível apenas para conectores selecionados” |
| Tratamento na carga | Treze regras de conversão encadeáveis por coluna, com oito formatos regionais | Bloqueio, hash e troca do tipo de destino, por coluna |
| Testes de qualidade | Cinco tipos declarados dentro da etapa, com severidade por teste | Pela integração com dbt, no projeto de transformação |
| Unidade de cobrança | Linha gravada no destino | Linha distinta alterada no mês (MAR); desde 1º de janeiro de 2026, exclusões também contam |
| No estouro do volume | Excedente cobrado, com teto de fatura por plano | teto não consta — há alerta de gasto por e-mail |
Onde o Fivetran aparece com não consta, é o que o material público dele não cobre — não uma afirmação de que o recurso não exista.
As seções abaixo abrem cada linha.
Quem escreve o conector que falta
Aqui os dois produtos partem de decisões opostas, e vale dizer com todas as letras: o catálogo do Fivetran é enorme. São mais de 700 conectores prontos. Se todos os seus sistemas estão nessa lista, alguém já resolveu autenticação, paginação e schema por você.
O Januss não tem catálogo de aplicativos. Ele conecta em cinco bancos, MongoDB, planilhas e diretório de arquivos — e em qualquer API REST que você apontar. Essa última não é mais uma origem na lista: ela cobre todo sistema que publica documentação.
Você aponta para a especificação OpenAPI ou cola a documentação escrita, e a IA monta o conector e o catálogo de tabelas. Ela resolve como a API pede autenticação, entre seis formas suportadas, e como o resultado é partido em páginas.
A IA escreve o conector uma vez. Depois disso ele é determinístico: a extração roda sempre igual, sem IA no caminho do dado. E a configuração não é aceita sem verificação — antes de salvar, o Januss faz uma chamada real e confere se conseguiu ler o retorno. Conector que falha não entra.
O Fivetran também tem caminho para a API que não está no catálogo, o Connector SDK. A documentação descreve o que ele pede: um script connector.py em Python, um requirements.txt com as dependências, um configuration.json com as credenciais, teste local e publicação com fivetran deploy.
É uma via aberta e bem documentada. Só que ela devolve o trabalho para o seu time: alguém escreve o código, alguém testa e alguém mantém quando a API mudar.
A diferença muda a pergunta que decide a avaliação. Deixa de ser “vocês têm esse conector?” e passa a ser “essa API está documentada?”. A primeira depende do planejamento de produto de outra empresa; a segunda você responde hoje.
Exemplo prático
Uma operadora de logística puxa dados do Salesforce, do Google Analytics e de um sistema de roteirização feito sob medida há oito anos. Os dois primeiros conectam em minutos nos dois produtos. O terceiro não está em catálogo nenhum: no Januss ele sai da documentação da API; no Fivetran ele vira um projeto de Python que alguém do time vai manter. É a origem diferente que define o cronograma.
O que dá para tratar durante a carga
O Fivetran é ELT em estado puro: o dado chega cru ao destino e a limpeza acontece depois, em SQL. Na carga, o que a documentação descreve por coluna é bloquear, aplicar hash e sobrescrever o tipo de destino. Conversão de formato não consta.
O Januss trata o formato na própria carga. São treze regras de conversão que você encadeia por coluna — moeda, data, número, texto, expressão regular, mapa de valores — com oito formatos regionais. R$ 1.234,56 vira número e 25/08/2026 vira data sem script de cola no meio.
E você decide, coluna a coluna, o que fazer com o valor que não converte: derrubar a execução ou gravar vazio. É uma escolha explícita, não um comportamento que você descobre no relatório.
Depois vêm os testes. O Januss aplica cinco tipos declarados sobre o resultado: não nulo, único, valores aceitos, integridade entre tabelas e uma consulta sua. Cada teste tem severidade própria — parar o pipeline ou apenas avisar. Parar significa que o número errado não chega ao painel.
No Fivetran, esse papel é do dbt. A própria documentação recomenda o dbt e o pacote dbt-expectations para aplicar testes, e os modelos prontos já vêm com verificação de chave primária. Funciona — com uma ferramenta a mais no caminho, e com o teste rodando depois que o dado já está no destino.
São duas arquiteturas, não duas listas de recurso. Uma trata na entrada; a outra trata na saída.
Parar o pipeline é o recurso. O número errado não chega ao painel.
O que o histórico custa
Se a sua análise depende de como o dado estava, e não só de como ele está, essa seção é a que mais pesa.
No Januss, o modo de sincronização é escolhido por tabela: carga completa, incremental, espelhamento ou histórico versionado, com data de início e fim de vigência. A mesma origem pode ter tabelas em modos diferentes dentro do mesmo pipeline. Quem precisa de histórico é a tabela de preço, não o cadastro de estados.
O Fivetran faz SCD tipo 2 pelo modo histórico, gravando _fivetran_active, _fivetran_start e _fivetran_end. A documentação traz duas ressalvas na mesma página. A primeira: o modo histórico “está disponível apenas para conectores selecionados”.
A segunda é sobre a conta. Nas palavras do próprio material, ligar o modo histórico em tabelas que mudam muito “pode aumentar o seu uso de MAR”. O motivo está na mesma frase: “cada atualização ou inserção na origem resulta numa linha nova inserida no destino — e toda linha nova conta como MAR pago”.
Vale ser justo: o efeito não é exclusivo. No Januss, histórico versionado também grava uma linha por versão, e linha gravada é a unidade da conta. A diferença não está em quem cobra pelo histórico. Está no que acontece quando essa soma cresce — que é o assunto da próxima seção.
A unidade de cobrança e o limite da fatura
Os dois modelos são por volume, e as unidades não são a mesma coisa.
O Fivetran cobra por MAR, monthly active rows: as linhas distintas sincronizadas da origem para o destino num mês civil, rastreadas pela chave primária. A mesma linha conta uma vez no mês, por mais vezes que sincronize. Desde 1º de janeiro de 2026, inserções, atualizações e exclusões contam como MAR pago.
O Januss cobra por linha gravada no destino, somando cada etapa que grava.
As duas unidades não se comparam entre si, e forçar a comparação não diz nada. Uma linha atualizada trinta vezes no mês é um MAR e são trinta linhas gravadas. O que dá para comparar é o comportamento no limite.
No Januss, cada plano inclui um volume, cobra por milhão adicional e tem um teto que a fatura não ultrapassa — sempre menor que a mensalidade do plano seguinte. O consumo aparece na tela em tempo real, com aviso em 80% e em 100% da franquia. Volume alto não vira surpresa: vira o teto.
No Fivetran, o material público descreve alerta de gasto por e-mail, com limite que você configura, mais um aviso quando faltam 45 dias para o saldo acabar. Teto automático de fatura não consta.
Alerta avisa. Teto para.
Como decidir
Quatro perguntas resolvem a maior parte dos casos:
1. O seu dado pode sair da sua rede — e pode sair do Brasil? Se a resposta for não, confira em qual plano o componente de execução local aparece, e quais geografias de processamento estão na lista.
2. Quantas das suas origens vão precisar de código? Todas em catálogo, e o catálogo ganha com folga. Alguma fora, e a pergunta vira quem escreve e quem mantém esse conector.
3. Quem limpa o dado, e onde? Na carga, coluna a coluna, ou depois, no destino, com uma ferramenta de transformação a mais no caminho.
4. No estouro de volume, o que você precisa que aconteça? Um e-mail avisando, ou um número que a fatura não passa.
Nenhuma das quatro tem resposta certa no abstrato. Todas têm a sua.
Onde o Januss entra
O Januss foi construído para o cenário em que o dado mora em banco, a rede tem fronteira e a fatura precisa de um número que ela não passa.
Execução dentro da sua rede pelo Runner, em qualquer plano, com uma única conexão de saída na 443. Região de processamento no Brasil ou nos Estados Unidos. Leitura do log de transações em cinco bancos, desde o plano de entrada. Modo de sincronização escolhido por tabela, incluindo histórico versionado. Conector de API escrito pela IA a partir da documentação e validado por chamada real antes de salvar. Treze regras de conversão por coluna. Testes que param o pipeline antes de o número errado chegar ao painel. E teto de fatura em contrato.
Se esse é o seu cenário, a lista acima não é folheto: é o produto.
Quer comparar com o seu caso real? 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 destino no mesmo dia.