If your Fivetran invoice looks different from the one you remember, it is not your imagination. On March 1, 2025 Fivetran moved from account-level to connection-level monthly active rows (MAR), retired the Starter and Private Deployment plans, and made rows re-synced because of a Fivetran-side change free. More pricing updates followed in 2026. This tutorial explains what that means in practice and what you can do about it. It is written for the person who owns the Fivetran bill, whether that is a data engineer or a finance analyst who has been handed one.
Fivetran's own reference for everything below is the usage-based pricing documentation and its pricing updates page. Check those for the current numbers; this article is about the mechanics.
What a monthly active row is
A row counts as active in a billing month the first time Fivetran inserts, updates, or deletes it in your destination during that month. After that, the same row can change a thousand more times in the month and it still counts once. A row that does not change does not count at all.
Three consequences follow:
- Initial syncs are expensive. Every row in a new source is active in the month you connect it. (New connections get a 14-day free-use period, which softens this; time your historical loads accordingly.)
- Churn matters more than volume. A ten-million-row table that barely changes costs less than a one-million-row table where every row is touched daily.
- Re-syncs reset the clock. A full re-sync on a large table re-activates every row. Re-syncs Fivetran itself initiates are free; the ones you trigger are not.
What changed with connection-level MAR
Under the old model, MAR from all connections was pooled, and volume tiers applied to the total. Under the current model, each connection is priced on its own MAR, on its own tier. Two things happen:
- Small connections that were riding on the account's volume discount now sit on a lower, more expensive tier.
- The shape of your connections becomes a cost decision. Splitting one source into several connections, or running duplicate connections for dev and prod, is no longer free of consequence.
The 2026 updates adjusted tiers and a few counting rules; the principle is unchanged. Read the pricing-updates page before your renewal.
Reading your usage
The Usage page in the Fivetran dashboard shows MAR per connection for the current and previous billing periods, and you can drill into schema and table level. That is enough for a quick look. For anything systematic, enable the Fivetran Platform Connector (free, it syncs Fivetran's own metadata into your destination) and query the incremental_mar table, which holds daily MAR by connection, schema, and table.
A query we run at the start of every cost audit, adjusted for your destination's schema name:
select
connection_id,
schema_name,
table_name,
sum(incremental_rows) as mar_this_month
from fivetran_platform.incremental_mar
where measured_date >= date_trunc('month', current_date)
group by 1, 2, 3
order by mar_this_month desc
limit 50;
In most accounts the top ten tables in that list account for the majority of MAR, and at least two of them feed nothing anyone looks at.
Estimating a new source before you connect it
Before adding a source, estimate two numbers:
- Initial MAR: total row count across the tables you will select. This is the first-month cost (minus the free-use period).
- Steady-state MAR: rows inserted, updated, or deleted per month. For a database source,
pg_stat_user_tables(Postgres) or the equivalent system views give youn_tup_ins + n_tup_upd + n_tup_delper table; divide by the stats window to get a monthly rate. For SaaS sources, ask the application owner how many records change per month, and assume API sources touch more rows than you think (status fields,updated_atbumps from automations).
Put the steady-state number against the tier for that connection and you have a defensible estimate. If the number is alarming, it usually means one or two tables should be deselected from the start.
Five concrete ways to cut MAR
1. Deselect columns and tables you do not use. This is the biggest lever and the least used. Trace each table to a dbt model or a BI query; if nothing reads it, deselect it. Column deselection matters too: a last_seen_at column that bumps every row hourly makes the whole row active, even if you only need email and plan.
2. Lower sync frequency on cold sources. Frequency does not change MAR directly (a row updated ten times a month is one MAR either way), but it does change how many distinct rows end up touched in a month for sources with short-lived churn, and it reduces compute on your destination. Nightly is right for most finance and HR sources.
3. Avoid unnecessary re-syncs. Restrict who can trigger a full re-sync in the Fivetran dashboard. When a re-sync is genuinely needed, re-sync the table, not the connection. And check your invoice: re-syncs caused by Fivetran (connector upgrades, schema migrations) should not be billed.
4. Archive dead connections. Paused connections do not accrue MAR. Sandbox, proof-of-concept, and "temporary" connections pointed at production-sized sources are the classic leak. Audit monthly; pause anything whose owner cannot name a consumer.
5. Monitor with the Platform Connector. Set an alert on week-over-week MAR growth per connection. A new automation in your CRM that rewrites every record nightly will show up as a MAR spike days before it shows up as an invoice. A simple alert query:
with daily as (
select connection_id, measured_date, sum(incremental_rows) as rows
from fivetran_platform.incremental_mar
group by 1, 2
)
select connection_id,
sum(case when measured_date >= current_date - 7 then rows end) as last_7d,
sum(case when measured_date < current_date - 7
and measured_date >= current_date - 14 then rows end) as prior_7d
from daily
group by 1
having sum(case when measured_date >= current_date - 7 then rows end)
> 1.5 * sum(case when measured_date < current_date - 7
and measured_date >= current_date - 14 then rows end);
Structuring connections under per-connection pricing
A few patterns that work:
- One connection per source system per environment, not per team. Duplicate connections to the same source double the MAR.
- Isolate the noisy table. If one event table dominates a connection and only one team needs it, give it its own connection with its own schedule, so the rest of the source can sync more often without dragging the big table along.
- Dev against a sample, not production. Point development connections at a reduced copy of the source, or pause them outside working hours.
Before your renewal
Forecast MAR from source growth, not from last month. Pull twelve months of incremental_mar, fit a trend per connection, and add the sources you know are coming. Commit to the forecast, not the peak, and leave headroom for initial syncs of planned sources. If you would like a second pair of eyes on the numbers, our Fivetran cost optimization service starts with a free MAR audit.