How does Fivetran's Monthly Active Rows pricing count a row updated fifty times in one month?
answer
- billing counts rows, not row-writes
- distinct key, deduplicated per month
- frequency buys latency, not extra rows
- re-sync makes the whole table active
basics
~20 sOnce. Fivetran bills Monthly Active Rows: a distinct primary key that is inserted, updated or deleted during a calendar month counts as one active row no matter how many times it changed, so raising sync frequency alone does not multiply the bill.
solid answer
~50 sFivetran's consumption unit is the **Monthly Active Row (MAR)**: a distinct row, identified by its primary key, that Fivetran inserts, updates or deletes into a destination at least once during the billing month. The count is *deduplicated per month*, so a row touched fifty times is one MAR, not fifty. Two consequences follow. First, moving a connector from hourly to every-few-minutes syncs cuts latency without multiplying MAR — the same churning rows are simply delivered sooner. Second, the things that genuinely inflate the bill are *breadth* not *frequency*: syncing tables you never query, wide high-churn tables where nearly every row changes monthly, and full re-syncs, which touch every row in the table and therefore make the whole table active for that month. Control MAR by excluding unneeded tables and columns at the connector, and by treating re-syncs as a deliberate, budgeted action.
code
text · 7 lines-- table: orders (primary key = order_id)
-- during March:
order_id 1001 updated 50x (status transitions) -> 1 MAR
order_id 1002 inserted once -> 1 MAR
order_id 1003 inserted, then deleted -> 1 MAR
order_id 1004 never changed all month -> 0 MAR
-- March total for these rows: 3 MARgo deeper
Remember the unit is a row that changed during the month, counted once per primary key — not a row-write, not a byte, and not the total table size sitting in the warehouse.
Explain the deduplication clearly and derive the consequence: sync frequency is a latency knob, while table selection, churn rate and re-syncs are the cost knobs.
Show you operate the bill: per-table usage review, alerting on consumption anomalies, treating re-sync as a costed action, and pruning tables nobody queries before renegotiating a plan.
Own the model at portfolio scale — forecasting consumption from source churn, deciding which high-churn sources should never be on a per-row vendor model, and setting the guardrails that stop teams onboarding whole schemas by default.
## The billing unit Fivetran prices on consumption, and the unit is the **Monthly Active Row**. The definition that matters in an interview: a row is *active* in a month if Fivetran writes a change for it — an insert, an update, or a delete — into a destination during that month, and each distinct primary key is counted **once per month** regardless of how many times it changed. Rows that sit unchanged all month are not billed even though they remain in the destination. So the answer to "a row updated fifty times" is one. This is the single most-asked thing about the product because it drives every downstream decision about how you configure it. ## Why frequency is not the cost lever people assume The instinct is that syncing more often costs more. Under a per-row-changed model, mostly it does not. Consider a table where 10,000 distinct rows change during a month: - Sync daily: those 10,000 rows are delivered in ~30 batches. 10,000 MAR. - Sync every fifteen minutes: the same 10,000 distinct rows are delivered in many more, smaller batches. Still 10,000 MAR. The row churn is a property of the *source*, not of your schedule. Higher frequency buys lower end-to-end latency at roughly the same MAR. It is not free in every sense — more frequent loads mean more, smaller write operations against the destination, which affects *warehouse* cost and can produce small-file or micro-partition pressure — but the ingestion vendor's line item is largely unmoved. ## What actually inflates MAR 1. **Syncing tables nobody queries.** The default temptation is to replicate an entire source schema. Every churning table in it is billable whether or not a single dashboard reads it. Excluding tables at the connector is the highest-leverage cost control there is. 2. **High-churn tables.** A table whose rows are stamped with a `last_seen_at` or a counter that updates constantly will show nearly 100% of its rows active every month, even though the business-meaningful changes are far fewer. These are the tables to interrogate: can you sync a narrower view, or a subset? 3. **Re-syncs.** A full historical re-sync re-writes every row in the table, which makes every row active for that month. On a large table this can dwarf a normal month's organic churn. Re-syncs are sometimes necessary — a schema fix, a corrupted load, a change to what columns are selected — but they are a budgeted decision, not a casual button. 4. **The initial sync.** The first sync of a connector backfills history, so the first month of a large source is atypical. Plan capacity and expectations around that rather than being surprised. 5. **Fan-out to multiple destinations.** If the same table is replicated into more than one destination, check how your plan counts it — do not assume one write equals one charge across all of them. ## Practical controls - **Column and table selection.** Deselect what you do not need. Narrowing columns does not reduce the row *count* but it reduces destination storage and, more importantly, reduces the chance that a churning column you never use marks a row active. - **Choose frequency for latency, not cost.** Set each connector's schedule by how fresh the consumers actually need it — a finance report that runs at 6am does not need minute-level syncs, and a fraud dashboard might. - **Treat re-sync as a change with a cost.** Ask what problem it fixes and whether a single-table re-sync would do instead of the whole connector. - **Watch usage continuously.** Fivetran exposes usage/consumption reporting; wire it into whatever your team uses for budget alerting so a runaway connector is caught in days, not at invoice time. - **Prefer log-based capture on databases where offered.** Reading the change stream rather than repeatedly comparing table state gives you the rows that genuinely changed, which is both cheaper on the source and closer to a true active-row count. ## Where this shows up in design MAR pushes you toward *deliberate* ingestion: a curated set of tables that someone actually consumes, with schedules matched to real freshness requirements. That is good hygiene regardless of vendor, which is why interviewers like the question — it tests whether you reason about a pipeline's cost model at all, not just its correctness. A candidate who says "we synced everything hourly because it was easier" has told you they have never seen the invoice. ## Version note Exact counting rules, plan tiers, volume-discount curves and which connector types are billed differently all change; never quote rates from memory. What is stable enough to reason from is the *shape*: per-changed-row, deduplicated within the month.
- Does moving a connector from daily to every-five-minutes syncs multiply the bill?Not materially under a per-active-row model — the same distinct rows change during the month, they just arrive sooner. What it does change is destination-side cost: many more small write operations, more micro-partitions or small files, and more compute churn in the warehouse. Choose frequency from the consumer's freshness requirement, then check the warehouse bill, not the ingestion one.
- A connector's monthly usage suddenly tripled. Where do you look first?Check whether a re-sync ran, on the whole connector or a table — that makes every row active for the month. Then check whether new tables or a new source schema got selected, and whether a source-side change now stamps every row (a bulk backfill, a new updated_at trigger, a mass reclassification). Compare per-table usage month over month rather than the connector total.
- How do you reduce active rows on a table where nearly every row changes each month?Interrogate why. Often a single churning column — a counter, a last_seen timestamp — drives it while the business-relevant fields are stable. Options: sync a narrower source view that excludes the noisy column, restrict to the row subset consumers query, or reconsider whether the table belongs in the warehouse at that grain at all.
- Does a row that is inserted and then deleted in the same month count once or twice?Once. The unit is the distinct primary key touched during the month, not the number of change operations applied to it. Insert, update and delete all mark the same key active, and the month's count deduplicates them.
It is a monthly turnstile count, not a step counter: the same person passing through fifty times still registers as one visitor for the month.
saying these in an interview costs you the question
- Says each update to a row is billed separately
- Claims syncing more often multiplies the vendor bill
- Treats a full re-sync as free and reversible
- Thinks unchanged rows sitting in the destination are billed
- Never considers cost when choosing which tables to replicate