Januss or Fivetran: what sits behind the Enterprise plan

Cover image

A dashed perimeter marking the customer network. On one side the whole pipeline runs inside it; on the other, the data crosses the line and goes up to the cloud.

Every evaluation of a data integration tool starts with the connector list. It is the easiest criterion to compare: you open both pages, look for your systems and count how many show up on each.

But the list is the floor. Fivetran and Januss both read the transaction log of the common databases, transform in SQL inside the destination and schedule the load. At that level, both solve the same problem.

The problem is that the real decision is not there. It is in three questions that rarely fit into a demo: where that data is processed, what you can change about it during the load, and what the bill does when volume grows.

In this article we compare the two products point by point, always from Fivetran's public material. Five axes: where the data runs, where it comes from, what you can do with it on load, what history costs and how each platform counts what it charges for.

Where your data is processed

Start here, because it is the axis whose answer changes most with the plan — and the one that shows up least in a demo.

When the data cannot leave your network, Januss installs the Runner inside it. It talks to the platform over a single outbound connection on port 443, with no inbound firewall rule. Extraction, transformation and load all happen in there, and the data never passes through the cloud.

This is not a higher-tier item. It is how the product works, from the entry plan on. When execution does happen in the cloud, the region is the account's choice: Brazil or the United States.

Credentials follow the same logic. They are encrypted in your browser, before they leave your machine, and the platform stores only the encrypted package — the executor is what opens it, at the moment of the run.

Fivetran has an equivalent model for the first part, Hybrid Deployment: an agent in your network, with outbound communication. Per the documentation, “only metadata (including MAR information) and logs are sent to Fivetran”. The same page also says you “must have an Enterprise or Business Critical plan to use the Hybrid Deployment model”.

On region, the public material lists twelve processing geographies: United States, Canada, European Union, United Kingdom, Australia, Singapore, India, Japan, South Korea, Indonesia, Middle East and Switzerland. Brazil is not on the list. Choosing the cloud provider requires an Enterprise plan; choosing the specific region, Business Critical.

Figure 1 — which rung each capability sits on

Two plan ladders side by side. On the Januss one, the in-network execution and region markers appear on the first rung. On the Fivetran one, in-network execution appears on the third and specific region only on the fourth.

If your legal team has already written data residency into a contract, this axis decides on its own.

The two, side by side

Before we break it down, the whole picture:

Where Fivetran shows not listed, that is what its public material does not cover — not a claim that the capability does not exist.

The sections below open up each row.

Who writes the connector you are missing

Here the two products start from opposite decisions, and it is worth saying plainly: Fivetran's catalog is huge. More than 700 ready-made connectors. If all your systems are on that list, someone has already solved authentication, pagination and schema for you.

Januss has no app catalog. It connects to five databases, MongoDB, spreadsheets and a file directory — and to any REST API you point it at. That last one is not one more source on the list: it covers every system that publishes documentation.

You point at the OpenAPI spec or paste the written documentation, and the AI builds the connector and the table catalog. It works out how the API asks for authentication, among six supported schemes, and how the result is split into pages.

The AI writes the connector once. After that it is deterministic: the extraction runs the same way every time, with no AI in the data path. And the configuration is not accepted without a check — before saving, Januss makes a real call and confirms it could read the response. A connector that fails does not get in.

Fivetran also has a path for the API that is not in the catalog, the Connector SDK. The documentation describes what it asks for: a connector.py script in Python, a requirements.txt with the dependencies, a configuration.json with the credentials, local testing and shipping with fivetran deploy.

Figure 2 — two routes to the same connector

On top, API documentation goes in and the connector comes out validated by a real call. Below, the same starting point runs through writing the code, installing dependencies, testing and shipping before reaching the connector.

It is an open, well-documented route. It just hands the work back to your team: someone writes the code, someone tests it and someone maintains it when the API changes.

The difference changes the question that decides the evaluation. It stops being “do you have that connector?” and becomes “is that API documented?”. The first depends on another company's product roadmap; the second you can answer today.

What you can clean up during the load

Fivetran is ELT in its pure form: the data lands raw at the destination and the cleanup happens afterwards, in SQL. On load, what the documentation describes per column is blocking, hashing and overriding the destination type. Format conversion is not listed.

Januss handles the format during the load itself. There are thirteen conversion rules you chain per column — currency, date, number, text, regular expression, value map — with eight regional formats. R$ 1.234,56 becomes a number and 25/08/2026 becomes a date with no glue script in between.

And you decide, column by column, what happens to a value that will not convert: fail the run or write it empty. That is an explicit choice, not a behavior you find out about in the report.

Then come the tests. Januss applies five declared types over the result: not null, unique, accepted values, referential integrity and a query of your own. Each test has its own severity — stop the pipeline or just warn. Stopping means the wrong number does not reach the dashboard.

On Fivetran, that role belongs to dbt. The documentation itself recommends dbt and the dbt-expectations package for applying tests, and the pre-built models already ship with primary key checks. It works — with one more tool in the path, and with the test running after the data is already at the destination.

These are two architectures, not two feature lists. One handles it on the way in; the other handles it on the way out.

Stopping the pipeline is the feature. The wrong number never reaches the dashboard.

What history costs

If your analysis depends on how the data was, and not only on how it is, this section carries the most weight.

On Januss, the sync mode is chosen per table: full load, incremental, mirroring or versioned history, with validity start and end dates. The same source can have tables in different modes inside one pipeline. The table that needs history is the price table, not the list of states.

Fivetran does SCD type 2 through history mode, writing _fivetran_active, _fivetran_start and _fivetran_end. The documentation carries two caveats on the same page. First: history mode “is available only for select connectors”.

The second is about the bill. In the material's own words, enabling history mode on tables that change often “can increase your MAR usage”. The reason is in the same sentence: “each record update or insert in the source results in a new row being inserted into the destination — and every new row counts toward paid MAR”.

To be fair: the effect is not exclusive. On Januss, versioned history also writes one row per version, and a written row is the billing unit. The difference is not who charges for history. It is what happens when that sum grows — which is the next section.

The billing unit and the invoice limit

Both models are volume-based, and the units are not the same thing.

Fivetran charges by MAR, monthly active rows: the distinct rows synced from source to destination in a calendar month, tracked by primary key. The same row counts once in the month, however many times it syncs. Since January 1, 2026, inserts, updates and deletes all count toward paid MAR.

Januss charges per row written to the destination, summing each step that writes.

The two units do not compare to each other, and forcing the comparison says nothing. A row updated thirty times in a month is one MAR and thirty written rows. What you can compare is the behavior at the limit.

On Januss, each plan includes a volume, charges per additional million and has a ceiling the invoice does not go past — always lower than the next plan's subscription. Consumption shows on screen in real time, with warnings at 80% and 100% of the allowance. High volume does not become a surprise: it becomes the ceiling.

On Fivetran, the public material describes an email spend alert, with a threshold you configure, plus a warning 45 days before the spend balance runs out. An automatic invoice ceiling is not listed.

Figure 3 — alert and ceiling

Two cost curves across a month. In the first, the curve crosses the configured threshold, an envelope marker appears and the curve keeps climbing. In the second, the curve meets the invoice ceiling and flattens out. Axes labeled as an example.

An alert tells you. A ceiling stops.

How to decide

Four questions settle most cases:

1. Can your data leave your network — and can it leave your country? If the answer is no, check which plan the in-network execution component sits on, and which processing geographies are on the list.

2. How many of your sources will need code? All of them in the catalog, and the catalog wins comfortably. Any of them outside it, and the question becomes who writes and who maintains that connector.

3. Who cleans the data, and where? On load, column by column, or afterwards at the destination, with one more transformation tool in the path.

4. When volume goes over, what do you need to happen? An email telling you, or a number the invoice does not pass.

None of the four has a right answer in the abstract. All four have yours.

Where Januss comes in

Januss was built for the case where the data lives in a database, the network has a boundary and the bill needs a number it does not go past.

Execution inside your network through the Runner, on any plan, over a single outbound connection on 443. Processing region in Brazil or the United States. Transaction log reading on five databases, from the entry plan on. Sync mode chosen per table, versioned history included. An API connector written by the AI from the documentation and validated by a real call before it is saved. Thirteen conversion rules per column. Tests that stop the pipeline before the wrong number reaches the dashboard. And an invoice ceiling in the contract.

If that is your case, the list above is not a brochure: it is the product.

Want to compare it against your real setup? It is a 14-day trial, no credit card: create your environment.