Quem procura uma plataforma de integração de dados no Brasil chega rápido às mesmas duas ou três opções. Preço em real, nota fiscal, suporte em português e um time no mesmo fuso são critérios que eliminam boa parte do mercado internacional antes da primeira conversa.
Só que isso é o piso, não o critério de escolha. Kondado e Januss cumprem os quatro. As duas cobram em real, oferecem 14 dias de teste sem cartão e levam dado de várias origens até bancos, planilhas e ferramentas de painel.
O que separa as duas não está na página de preços. Está no que cada uma faz com o dado depois que ele chega.
Neste artigo comparamos os dois produtos ponto a ponto. Cinco eixos: o histórico, a origem do dado, o que dá para fazer com ele depois, onde ele é processado e o que acontece no estouro de volume.
O que a demonstração não mostra
Comece por aqui, porque é a diferença mais funda entre os dois produtos — e a que menos aparece numa demonstração.
O Januss lê o log de transações do banco de origem. É o que se chama captura de mudanças, ou CDC, e funciona em PostgreSQL, MySQL, SQL Server, Oracle e MongoDB. Em todos os planos, inclusive o de entrada: não é item de plano enterprise.
Ler o log muda o que você consegue saber. Uma linha excluída na origem vira um evento registrado, não um registro que simplesmente sumiu da consulta. Um pedido que passa por três status entre duas execuções deixa os três no log, não só o último.
Daí vem a escolha por tabela. Carga completa, incremental, espelhamento ou histórico versionado, com data de início e fim de vigência — cada tabela no modo que a pergunta do negócio pede, dentro do mesmo pipeline.
O material público da Kondado não menciona leitura de log de transações. A página de conectores de banco descreve atualizações horárias, diárias ou em horários específicos, o que caracteriza consulta agendada. Na página principal, a frequência mínima anunciada é de cinco minutos.
Consulta agendada resolve para quem precisa do estado atual. Se a sua análise depende de como o dado mudou, ela não fecha.
As duas, lado a lado
Antes de destrinchar, o retrato inteiro:
| Januss | Kondado | |
|---|---|---|
| Origem dos dados | Conector gerado a partir da documentação da API, sem catálogo | Catálogo de mais de 80 fontes, com ERPs brasileiros nativos |
| Bancos de dados | PostgreSQL, MySQL, SQL Server, Oracle e MongoDB, por leitura do log de transações | Conectores dos mesmos cinco bancos |
| Frequência | A partir de 5 minutos e, nos bancos, captura contínua pelo log | A partir de 5 minutos; em bancos, horária ou diária |
| Histórico | Carga completa, incremental, espelhamento ou histórico versionado, por tabela | não consta |
| Transformação | Formato tratado na carga, e SQL em etapas com dependência entre elas | SQL materializado e documentado, disparado com a integração |
| Testes de qualidade | Declarados por tabela e coluna, com opção de parar o pipeline | não consta |
| Cobrança | Por linha gravada no destino | Por integração ativa e por volume, em bytes |
| No estouro do limite | Excedente cobrado, com teto de fatura por plano | Integrações pausadas até a virada do ciclo |
| Dado dentro da sua rede | Runner instalado na sua infraestrutura | não consta |
Onde a Kondado aparece com não consta, é o que o material público dela não cobre — não uma afirmação de que o recurso não exista.
As seções abaixo abrem cada linha.
De onde vem o dado
O Januss não trabalha com catálogo de aplicativos. Você aponta para a documentação técnica que a API publica, ou cola a documentação escrita, e a plataforma monta o conector e a lista de tabelas. Ela descobre sozinha como a API pede autenticação e como parte o resultado em páginas.
E não aceita a configuração sem verificar. Antes de salvar, faz uma chamada real e confere se conseguiu ler o retorno. Conector que falha não entra.
Isso 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?" — uma pergunta que você mesmo responde, sem depender do planejamento de produto de outra empresa.
A Kondado trabalha com catálogo: mais de 80 fontes prontas, com destaque para o mercado brasileiro — Bling, Omie, ContaAzul, Tiny, RD Station, Mercado Livre, VTEX, Nuvemshop, Asaas, Pagar.me e Hotmart, entre outras. Se o seu sistema está na lista, a conexão leva minutos e alguém já resolveu a autenticação por você.
Os dois caminhos resolvem problemas opostos. Catálogo ganha no sistema popular. Geração ganha no sistema que catálogo nenhum tem: a API interna do seu time, o sistema do seu setor, o software de nicho que a operação usa há dez anos.
Exemplo prático
Uma rede de clínicas usa Bling no financeiro e um sistema de gestão de agendamentos feito sob medida. A Kondado conecta o Bling em minutos e não conecta o sistema próprio, que não está em catálogo nenhum. O Januss gera os dois a partir da documentação: a do Bling, que é pública, e a do sistema feito sob medida. Uma resolve metade do caso; a outra resolve o caso.
Vale a pergunta direta: quantas das suas origens estão em catálogo, e quantas não estão?
O que dá para fazer com o dado depois
As duas plataformas transformam em SQL, no destino, e nenhuma exige Python ou dbt. A diferença está no que acontece antes e depois do SQL.
Antes, 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 19/08/2026 vira data sem script de cola no meio. E você decide, coluna a coluna, se o valor inválido derruba a execução ou é gravado vazio.
Depois, o Januss aplica testes declarados sobre o resultado: não nulo, único, valores aceitos, integridade entre tabelas ou uma consulta sua. Cada teste pode parar o pipeline ou apenas avisar. Parar significa que o número errado não chega ao painel.
E o pipeline não insiste no erro. Depois de três falhas seguidas ele se desliga sozinho, em vez de queimar franquia falhando em silêncio.
A Kondado chama as transformações de modelos: SQL disparado junto com as integrações, materializado e documentado campo a campo, o que ajuda quem for consumir depois.
Dado errado não passa é uma decisão de produto, não um recurso opcional.
Onde o dado é processado
O Januss cifra as senhas dos bancos no seu navegador, antes de saírem da sua máquina. A plataforma guarda o pacote cifrado e nunca o abre — só o executor, no instante da execução.
Há túnel SSH para banco que não está exposto, e a execução acontece na região que você escolher: Brasil ou Estados Unidos.
E quando o dado não pode sair da rede, existe o Runner. É um componente instalado dentro da sua infraestrutura, que fala com o Januss por uma única conexão de saída na porta 443. Extração, transformação e carga acontecem ali dentro. Sem regra de entrada no firewall.
A Kondado informa que os dados ficam na nuvem do cliente e descreve o uso de provedores de nuvem estabelecidos. Não há, no material público, componente equivalente para execução dentro da rede do cliente.
Se o seu jurídico já barrou uma ferramenta por causa disso, esse item pesa mais que todos os outros juntos.
O que acontece quando o volume estoura
Os dois modelos são por volume, e param aí a semelhança.
No Januss, a conta é por linha gravada no destino, somando cada etapa que grava. O que passa da franquia é cobrado por milhão adicional, e cada plano tem um teto que a fatura não ultrapassa — sempre menor que a mensalidade do plano seguinte. Volume alto não vira surpresa na fatura: vira o teto.
A Kondado cobra por dois limites: integrações ativas e registros inseridos com sucesso no destino. Um registro é uma linha de até 500 bytes, então 10 mil linhas somando 10 MB contam como 20 mil registros. Ao atingir o limite antes do fim do mês, as integrações são pausadas automaticamente até a virada do ciclo.
São duas respostas opostas ao mesmo risco. Uma protege o bolso e para o pipeline. A outra mantém o pipeline rodando e limita a conta. A pergunta é uma só: no dia em que o volume estourar, o que dói menos — o relatório desatualizado ou a fatura maior?
Como decidir
Quatro perguntas resolvem a maior parte dos casos:
1. Você precisa saber como o dado mudou? Se a análise depende do histórico, ou de saber o que foi excluído, você precisa de leitura de log.
2. Todas as suas origens estão em catálogo? Todas dentro, e o catálogo ganha. Alguma fora, e a geração a partir da documentação passa a valer.
3. Seu dado pode sair da sua rede? Se não pode, a conversa começa e termina no componente de execução local.
4. No estouro de volume, o que dói menos? Pipeline pausado ou fatura maior. Não existe resposta certa — existe a sua.
Onde o Januss entra
O Januss foi construído para o cenário em que o dado mora em banco, o histórico importa e nem toda origem cabe num catálogo.
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 gerado 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. Execução dentro da sua rede pelo Runner, quando for o caso. 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.