Does Your Fivetran Bill Jump Every Time a Source Table Gets Busy?

Monthly Active Rows (MAR) are a reasonable way to meter a connector. They turn into a problem when the number of rows that change is decided by somebody else. A bulk price update in the ERP, a schema migration that rewrites a column for every record, a data quality cleanup that touches half the customer table: each one counts every affected row as active again, and the bill arrives after the fact.

Why the bill is not under your control

• MAR counts rows touched, not rows that matter. A migration that changes one column on ten million records is ten million active rows, even if nothing downstream needed to change.
• The trigger sits upstream. Source system teams do not consult the ingestion budget before a bulk operation, and they should not have to.
• The same row is paid for twice. Once on the way in, and again in compute when the landing table is reprocessed in full because nothing downstream knows which rows changed.
• Forecasting is guesswork. The connector meters activity, and activity is a function of what other teams do.

Fivetran is doing exactly what it is priced to do. The question is whether per row metering is the right economics for your largest, busiest tables.

Where the cost actually belongs

• Ingestion of high volume tables is warehouse work. A model-driven platform loads them as part of generating the warehouse, on compute you already own.
• Only the delta should move downstream. An automated Data Vault architecture loads only what changed into hubs, links and satellites. A full reload in staging does not become a full reload of every layer above it.
• The long tail can stay on the connector. Managed connectors excel at low-volume SaaS sources where MAR remains small and predictable.

What changes with Datavault Builder

Datavault Builder includes its own ingestion: batch, delta and CDC loads from databases, files, REST APIs, NoSQL and Python sources, with streams such as Kafka arriving as micro batches, all from the same platform that generates the rest of the warehouse.

• The busy tables bypass per row charges. They land in staging through the platform, and the connector invoice stops tracking your ERP team’s project calendar.
• Reloads stay in staging. The generated vault loads compare against what is already historized and move only the delta, so a reload upstream is not a reload everywhere.
• Tables that keep using the connector are still decoupled. Raw landing tables and the historized layer are separate, so the choice of connector per table is yours and reversible.
• Cost is a sizing question. Warehouse compute is something you can measure, reserve and forecast. Row activity in somebody else’s system is not.

What to decide

Pull the MAR report for the last six months and sort by table. If the top five to ten tables carry most of the cost, that is the list to move to direct ingestion. Everything below the line can stay exactly as it is.