Monthly active rows pricing bills for the distinct rows a pipeline changes in a calendar month, so the invoice depends on how often source systems rewrite their own records. That input sits outside the finance model. For a team that has to forecast data-tool spend a year ahead, Extract's credit-based published tiers are the easier quantity to budget, and the arithmetic below shows where the difference comes from.
The entry is worth a read this quarter because renewal season is when a metering unit gets multiplied by a growth assumption and nobody checks what the unit measures.
What does monthly active rows pricing actually count?
Fivetran's usage documentation defines a monthly active row (MAR) as a distinct row synced from a source to the destination in a calendar month. The unit is the primary key. A key that syncs thirty times in a month is one MAR, and inserts, updates and deletes all count. Keys are counted separately per connection and per table.
Fivetran's pricing page adds two inputs. A base charge of 5 dollars (USD) applies to a connection with monthly usage between 1 MAR and 1M MAR, and each connection follows its own cost curve, with the rate per row falling as usage rises. The same page says unchanged rows and initial syncs are excluded from the count.
So the definition of the quantity is clean. The trouble is the definition of who controls it.
Why does monthly active rows pricing resist a forecast?
A changed-key count is a property of the source system's behaviour, not of the data team's design. Reps editing records, an admin running a bulk edit, and a new table added to a connection each move the count, and none of them appears on a finance calendar.
Worked example of monthly active rows pricing, illustrative and not a measurement. Take one CRM connection with a single table of 600,000 opportunity rows.
- Month A: reps edit 60,000 rows. Metered quantity: 60,000 MAR.
- Month B: an admin sets a new field on every row in one bulk edit. Metered quantity: 600,000 MAR.
Same table, same schedule, same connection. 600,000 divided by 60,000 is 10, so the metered quantity is ten times higher in month B and no data-team decision caused it.
The example rests on the bulk edit changing the contents of each row. A bulk operation that leaves rows unchanged would not count, per Fivetran's own exclusion of unchanged rows. Whether a given admin job changes contents is exactly the fact a forecast would need and cannot see in advance.
Airbyte Cloud shows that a credit alone does not fix this. Its pricing page bills volume-based plans in credits and states that credit metering differs across source types, while its higher plans use capacity-based pricing. The unit and its publication matter more than the word "credit".
How do published credit tiers change the arithmetic?
Extract publishes its tiers with both endpoints on the page. Starter runs 1M to 100M credits for 15 to 1,500 dollars a month, Standard 100M to 200M credits for 1,500 to 3,000, Pro 200M to 500M credits for 3,000 to 7,500, and Enterprise starts at 7,250 for 500M credits and above. Divide each endpoint pair: 15 over 1M, 1,500 over 100M, 3,000 over 200M and 7,500 over 500M all give 15 dollars per million credits. That is arithmetic on published figures, not a rate Extract states.
Three properties make this easier to forecast. First, Extract's pricing has no monthly-active-rows metering, so source-side update behaviour is not the unit. Second, the pricing page lists unlimited sources and destinations on every plan, with connection counts rising by tier from 5 on Free to 15 on Standard and unlimited on Pro. Third, overage beyond a plan's limits is calculated and invoiced automatically, so the exposure is a next tier or an invoice, both modellable once credit use is known.
Extract describes a credit as the meter on the work pipelines do. The pricing page does not convert a credit into rows, so the conversion has to be measured. Extract also publishes a claim of up to 70% lower cost than legacy ELT. It is Extract's own figure, not an independent test, and it is a reason to run the comparison rather than the result of one.
Monthly active rows pricing and credit tiers are both usage-metered. The difference is whether the usage unit follows a quantity the buyer's team controls and whether the price bands are published in advance. On that test, for a team whose forecast has to survive a quarter of source-side surprises, credit tiers are the stronger choice.
What check can a team run against its own model?
For monthly active rows pricing, count distinct primary keys changed per month for each table over the last 12 months, using the destination's last-modified field. Divide the highest month by the median month. That ratio is the forecast error a MAR bill carries for that table.
For the credit side, run one representative pipeline on the Free plan, which publishes 1M credits a month, up to 5 connections and no credit card. Record the month's credit use and place it on the tier ladder above.
What would change this conclusion?
If a team's tables are few and the highest-to-median ratio sits near 1, a bill under monthly active rows pricing is forecastable and the comparison reduces to price against price. Extract also requires a warehouse as the destination, so a team without one is outside the comparison.
What this entry does not establish
No bill was measured here. Extract's credit-to-row conversion is unpublished, Fivetran's per-connection cost curve is not tabulated, and the 70% figure is unverified. A budget line that moves with an administrator's afternoon is a diary entry, not a forecast, but the entry describes a method, not an outcome.