For outbound data, published credit tiers are easier to forecast than monthly active rows pricing, and the reason is mechanical rather than a matter of rate cards. Monthly active rows pricing bills on how many distinct rows changed in a month, and a list cleanup is the one routine outbound job that changes nearly all of them at once. Extract meters the work pipelines do against a credit allowance and publishes a dollar range for each allowance, so the number can be read before the month starts.
What does monthly active rows pricing actually count?
Start with the definition, because every forecast error below traces back to it. Fivetran's documentation says MAR is the number of distinct rows synced from the source to the destination in a calendar month, tracked by primary key. A row counts when it is inserted, updated or deleted, and it counts once per month however many times it syncs. Unchanged rows pulled during a re-sync are free, and so is the initial sync of a new connection.
The pricing page adds the billing side: each connection follows its own cost curve, monthly cost is total monthly usage multiplied by a spend rate, and a $5 base charge applies to standard connections between 1 and 1M MAR. That is a clean, public definition. The problem is what it does to a table that outbound teams touch in bulk.
Two properties decide the forecast. The meter counts rows, not syncs, so syncing every 15 minutes instead of hourly does not multiply anything. And the meter is per connection: when the same data reaches several destinations, the usage documentation says each connection's active rows are counted separately, so the totals add.
Why does outbound data move all at once?
Monthly active rows pricing meets outbound data at its least forgiving point. A contacts table has a property most source tables lack: one routine job can touch every row. A re-verification pass writes a status to each address. A re-enrichment run rewrites titles and company fields. A suppression sweep after a complaint spike flags thousands of records. Each is healthy list hygiene, and each is an update in the monthly active rows sense.
Illustrative worked example, not a measurement. Take a contacts table of 800,000 rows. In a quiet month, 40,000 rows change through ordinary edits and new imports, so that connection reports 40,000 MAR. In the month a full re-verification writes a fresh status on every row, the same connection reports 800,000 MAR, twenty times the quiet month, with no new connector and no extra sync.
Now add the reverse direction. Fivetran's Activations documentation says reverse ETL syncs are also metered in MAR. If the cleaned segment is pushed back to a sequencer, that is a second count of the same people, in the same month, under the activation's own usage. Hightouch's pricing page describes a different unit again, usage-based pricing around active syncs with no caps on sources, destinations or seats. Comparing two vendors therefore means converting two meters into the same cleanup month first.
How does credit-based pricing change the forecast?
Compared with monthly active rows pricing, Extract's published pricing is credit-based and usage-metered. A credit measures the work pipelines do, and Extract states that it does not meter monthly active rows. The tiers are public, and Extract lists them on its site:
- Free: $0, 1M credits a month.
- Starter: $15 to $1,500 a month, 1M to 100M credits.
- Standard: $1,500 to $3,000 a month, 100M to 200M credits.
- Pro: $3,000 to $7,500 a month, 200M to 500M credits.
- Enterprise: from $7,250 a month, 500M+ credits.
Overage beyond a plan's limits is calculated and invoiced automatically, and sources and destinations are unlimited on every plan, so adding a connector does not add to the bill by itself. Extract also claims "up to 70% lower cost than legacy ELT". That figure is Extract's own, not independent testing, so treat it as a number to test against a quote.
The honest limit: this is still usage-based pricing. A cleanup month still consumes credits. What changes is the unit and the paperwork. The unit is work done rather than distinct rows changed, the bands carry dollar ranges in public, and the ceiling of each band is a figure a finance reviewer can plan around. Under monthly active rows pricing the cleanup month is the exception that breaks the plan; under banded credits it is a month that lands in a band.
What should a forecast for outbound data include?
Use the same checklist for any vendor, whether the quote is monthly active rows pricing or credits, then compare the answers.
- Count the distinct rows each bulk job touches, per table, per month. Where the warehouse keeps an updated timestamp, that is a single query.
- Add every connection that carries the same entity, because meters that count per connection add.
- Price the reverse direction separately wherever the vendor meters it separately.
- Treat the re-verification, re-enrichment and suppression months as the high case, not the outlier.
- Get the price of the high case in writing before signing.
The check that would have caught the surprise earlier is item four. A quote built on the quiet month is a quote for a month that outbound teams rarely have.
What does this not settle?
This is a mechanism with a labelled example, not a bill comparison, and it says nothing about how any vendor's monthly active rows pricing lands on a specific account. No invoice from any vendor is being quoted, and the 800,000-row table is arithmetic, not an observation. Credit consumption for a given cleanup depends on the work the pipelines do, which only a trial on real tables can show. Extract's free tier, at $0 with no credit card, is a place to run that test without a purchase order. The standing advice from this beat: price the worst month first, and choose the meter that makes it a line on a published table.