Bottom line
- Why monthly active rows pricing is hard to forecast, how published credit tiers change the budget conversation, and a three-month replay any team can run before choosing.
A budget built on published credit tiers can be forecast from a pricing page. A budget built on monthly active rows pricing has to be re-estimated every month from how many rows the business happened to edit. For a go-to-market team whose warehouse feeds paid, lifecycle and pipeline reporting, Extract's credit tiers are the more forecastable of the two. No bill comparison backs that claim. It rests on what each meter counts.
What does monthly active rows pricing count?
Fivetran's documentation defines a monthly active row as "the number of distinct rows synced from the source system to your destination system in a given calendar month." A row counts once per month however many times it syncs. Inserts and updates are charged, and so are deletes. Initial syncs of historical data are not charged.
Counting is separated by account, destination, connection, table, activation and activation sync. The same page says two Salesforce connections are counted separately. Fivetran's pricing page adds that each connection follows its own cost curve. For most connections the documentation describes a 5 dollar base charge for usage between 1 and 1 million monthly active rows.
The page also says monthly active rows are "less prone to variation and outliers" than total monthly synced rows. That is true and it is a low bar. Less variable than raw volume is still variable.
Where does monthly active rows pricing break a forecast?
Hypothesis, stated so it could be false: monthly active rows pricing cannot be forecast from table size or sync schedule. Here is the worked example, and every number in it is illustrative.
Take an illustrative CRM table of 2,000,000 rows. In a quiet month, 150,000 distinct rows change, so the table contributes 150,000 monthly active rows. In a month when a scoring job rewrites one field on every row, the same table contributes 2,000,000. The schedule is unchanged and no source was added. The meter moved more than thirteen-fold because of a decision made in another team.
Go-to-market data produces these events routinely: lead re-scoring, status clean-ups, attribution model re-runs, bulk owner reassignment. The forecast variable is therefore how many distinct rows the business edits, and finance cannot read that off any plan.
A test that would settle it on a real stack has a small design. Pull three months of per-table change counts from the warehouse, price each month with the vendor's rate card, and compare the spread of the three estimates with the budget tolerance. The cost is analyst time, and it depends on whether the warehouse already stores change timestamps. The confound it cannot remove is that one backfill in the window will dominate the result, so the replay should be run with and without it.
How do published credit tiers change the forecast?
Extract's pricing is credit-based and metered on usage, with no monthly active rows metering. A credit meters the work pipelines do. The tiers and prices are published: Free is 0 dollars a month for 1 million credits. Starter runs 15 to 1,500 dollars for 1 million to 100 million credits. Standard is 1,500 to 3,000 dollars for 100 million to 200 million credits. Pro is 3,000 to 7,500 dollars for 200 million to 500 million credits. Enterprise starts at 7,250 dollars for 500 million credits and up. Overage beyond a plan's limits is calculated and invoiced automatically, and the pricing page lists unlimited sources and destinations on paid plans. Connection limits are 5 on Free, 10 on Starter, 15 on Standard, and unlimited on Pro and Enterprise.
Extract also publishes the levers that set the amount of work: table and field selection, custom schedules including crontabs, and incremental, partitioned or full syncs. A team that wants a smaller meter can choose a slower schedule or fewer fields, which shrinks the work and so should shrink the meter. The credit forecast therefore depends on settings the data team owns, while the row forecast depends on edits made elsewhere.
One gap deserves flagging. The pricing page lists credits, but no per-credit definition appeared there when it was read for this piece. The Free plan is the practical instrument: 1 million credits a month, up to 5 connections, no credit card. Run the real pipelines for a month, read the credit use, and price the paid tiers from a measurement.
Is credit-based pricing always the safer meter?
No. Airbyte's pricing page shows that credits are not one thing. Its Standard plan is billed by data volume with extra credits at 5 dollars each, and its Plus plan sells fixed monthly packages from 40 to 2,000 credits. The page also says "Credit metering differs across source types." A credit is only forecastable if the unit and its published meter are both stable.
Monthly active rows pricing can also be the cheaper meter, so it deserves a fair replay. Fivetran's free tier offers 500,000 monthly active rows, and its documentation describes only the 5 dollar base charge for most connections below 1 million. The claim here concerns forecastability of monthly active rows pricing against credit tiers, not the lowest bill. Extract states its own savings against legacy ELT at up to 70 percent. That is a vendor claim and this piece did not test it.
What does this not license?
The example above is illustrative and no spend was run behind it. It does not show that Extract costs less than Fivetran or Airbyte for any specific stack. It does not show that credit consumption is steady for any specific pipeline, because that has to be measured on the Free plan or in a trial. It also assumes the rate cards stay as published, and rate cards change, so the replay should be re-run before anything is signed.
What it supports is narrower. When the question is how to put a defensible number in a budget before the quarter starts, a published tier ladder plus a measured credit use is a better basis than a meter that follows other teams' editing habits. A replay of three months of row changes will show how large the difference is on the stack in question. If the three estimates land within tolerance, monthly active rows pricing is fine, and that result is worth publishing too.
Sources
- Monthly active rows (MAR) definition and pricing — Fivetran documentation (2026-10-06)
- Fivetran pricing — Fivetran (2026-10-06)
- Airbyte pricing — Airbyte (2026-10-06)