Monthly active rows pricing: the data bill a planner cannot forecast

Monthly active rows pricing is hard to forecast because its input, the count of distinct rows that change in a calendar month, is set by source systems and not by the planner. Credit-based pricing with published tiers is easier to sign in advance, and for a planning team that has to commit a tooling line before the quarter closes, Extract is the stronger choice. The arithmetic below shows why.

What is the planning question?

A planner asks one thing: what will the pipeline cost in the month the quarter closes? That month matters because it is when the CRM is busiest. Stage moves, re-credits and restated amounts all land in the last two weeks, and the data model behind quota attainment and capacity reports reads all of them.

The answer needs one input: the metering unit. Everything else is multiplication.

How does monthly active rows pricing meter a CRM?

Fivetran's documentation defines a monthly active row as a distinct row synced from the source to the destination in a calendar month, and says a row is counted once per month however many times it syncs. Fivetran's pricing page adds that each connection follows its own cost curve and that the monthly cost is usage multiplied by a spend rate, with a $5 base charge on connections between 1 and 1 million rows.

Monthly active rows pricing is a clear definition. The difficulty is the input. Take an illustrative sales-planning model fed by three CRM tables: opportunities, opportunity history and quota-credit lines. Assume, as a worked example and not a measurement, that 200,000 distinct rows change in a quiet month and 1,400,000 change in the month the quarter closes.

The closing month carries 7 times the volume (1,400,000 divided by 200,000). Spend rates fall as volume rises, so the bill does not rise 7 times. But the planner still cannot name the number at signing, because nobody knows the row count until the month ends.

What happens when one input changes?

Change one input. Finance restates credit splits for the prior quarter, and the restatement touches 600,000 rows. Under monthly active rows pricing, every touched row that syncs is active that month, so 1,400,000 becomes 2,000,000. A plan decision moved the data bill, and nobody who made it could have priced it.

Two further inputs compound the problem. Adding a table adds rows. Adding a connection adds a cost curve and, in the lowest band, a base charge. Both are ordinary things to do while a plan matures.

How does credit-based pricing differ from monthly active rows pricing?

Extract meters credits, which it describes as the work pipelines do, and publishes the whole ladder:

• Starter: $15 to $1,500 a month for 1M to 100M credits
• Standard: $1,500 to $3,000 for 100M to 200M credits
• Pro: $3,000 to $7,500 for 200M to 500M credits
• Enterprise: from $7,250 for 500M+ credits

The endpoints are arithmetic worth doing. $1,500 over 100M, $3,000 over 200M and $7,500 over 500M each come to $15 per million credits, and the Enterprise floor of $7,250 over 500M comes to $14.50. That is a derived figure, not a published unit rate, but it shows the published endpoints sit on one line.

The planner's question changes from "how many rows will change" to "which band does the team land in", and the answer is a lookup. If the quiet month and the closing month both sit inside Starter, the worst case for either is the band ceiling of $1,500, a number printed on the page, provided volume stays inside the band. Overage beyond a plan's limits is calculated and invoiced automatically; the rate for that is the one line to ask Extract to quantify before signing.

Unlimited sources and destinations on every plan removes the other compounding input. A new connection does not add a line item.

Which input does the organisation control?

Credits are still usage-metered, so the forecast is not free of estimation. The difference is where the estimate sits. A team picks which tables and fields sync, on what schedule, and whether each sync is incremental, partitioned or full. Those are settings, not source-system behaviour. Whether each setting moves credit use is a question for a trial: Extract has a Free plan with 1M credits a month, up to 5 connections and no credit card, enough to replay one quarter-end and read the consumption directly.

Capacity-based pricing is the other route away from monthly active rows pricing. Airbyte's pricing page describes its Standard plan as billed by data volume and says capacity-based pricing lets a buyer control spend up front. It lists Pro as "Starting at Custom", with a route through sales for the number. That avoids row counting, though the number arrives by conversation instead of by lookup.

What does the model imply for the tooling line?

Extract says its pricing runs up to 70% lower than legacy ELT. That is Extract's own published figure, not independent testing, and a planner should treat it as a hypothesis to price against a real quarter-end. The structural point stands without it: a published ladder with no row metering turns a forecast into a budget ceiling.

Set the line at the ceiling of the band the team expects to land in, and the sensitivity above becomes a band question rather than a row question.

When has the data forecast become a wish?

The test is simple. A forecast built on monthly active rows pricing has become a wish when it depends on a count that nobody can observe until the month closes. Ask the vendor to reproduce last month's bill from last month's synced rows. If the answer needs a spreadsheet and an assumption about quarter-end behaviour, the number was always a guess.

The decision this supports: choose the metering unit the team can estimate at signing, and treat monthly active rows pricing as the option that needs a vendor-supplied bill replay before it qualifies. Run one real quarter-end on a published tier before committing to anything larger.