Data pipeline pricing explained: MAR, rows, and what you actually pay
Data pipeline pricing is hard to compare because every vendor meters differently. This is a plain-English tour of the main models — monthly active rows (MAR), rows moved, connectors, and compute credits — and how to work out your real bill before you sign.
If you've priced out more than one data movement tool, you already know the problem: two quotes for the same workload can differ by an order of magnitude, and it's rarely obvious why. The culprit is almost always the unit. One vendor bills on monthly active rows, another on total rows moved, a third on compute credits. Same data, different meter, wildly different math. Understanding data pipeline pricing starts with understanding what, exactly, is being counted.
Why data pipeline pricing is confusing
There's no industry-standard unit for "moving data." A pipeline reads changes from a source, ships them to a destination, and does some transformation along the way — and a vendor can meter any point in that path. They can count rows that changed, rows that landed, the number of connectors you run, the seats on your team, or the raw compute the sync consumed. Each of these is a defensible way to price, and each rewards a different usage pattern.
That's why a workload that looks cheap on one platform looks expensive on another. Your bill isn't really a function of "how much data you have" — it's a function of how your specific change patterns map onto whatever unit the vendor happens to count.
The main pricing models
Five models cover almost everything you'll encounter. Here's how each one actually works:
- Monthly active rows (MAR). You pay for each unique row that is inserted, updated, or deleted at least once in a billing month. Touch a row a hundred times and it still counts once. Popular with ELT vendors because it decouples price from update frequency.
- Rows or events moved. You pay per record shipped, every time. A row updated fifty times is fifty billable events. Simple and transparent, but high-churn tables get expensive fast.
- Connectors or seats. A flat fee per source connector or per user, regardless of volume. Predictable, but you pay the same whether a connector moves a thousand rows or a billion.
- Compute or credits. You pay for the processing the sync consumes — often as credits tied to warehouse or cluster time. Flexible, but the bill depends on engine efficiency you don't fully control.
- Flat platform fee. A fixed subscription for a usage band, sometimes with overage above a cap. Easy to budget until you outgrow the tier.
No model is inherently "cheaper." Volume-based models (MAR, rows moved, compute) reward small or slow-changing datasets and punish churn. Capacity-based models (connectors, seats, flat fee) reward high volume and punish light users who still need many sources.
Your bill isn't set by how much data you have. It's set by how your change patterns map onto the unit a vendor chose to count.
The catch with monthly active rows
MAR is the model most likely to surprise you, in both directions. The appeal is real: because a row counts once per month no matter how many times it changes, a high-churn table that would be ruinous under per-event pricing can look almost free under MAR. If you have a table where the same ten thousand records update constantly, MAR is your friend.
The catch is the definition of "active." Vendors differ on what trips the counter. Does a row that only gets deleted count? Does re-reading an unchanged row during a sync count? Do all columns of a wide table count as one row, or does the tool fan out somewhere? These details rarely appear in the headline price, and they're exactly where a "cheap per-MAR" quote quietly inflates.
The bigger risk is predictability at scale. MAR looks flat until your active-row footprint grows — a new high-cardinality source, a table that suddenly touches every row nightly, a schema that turns one logical entity into many. Because you're billed on unique rows touched, your cost can step up sharply in ways that are hard to forecast from last month's invoice.
How to estimate your real bill
The only reliable estimate comes from mapping your change volume onto the vendor's unit — not from the price on the page. Start by pulling a few real numbers from your sources: how many rows change per day, how concentrated those changes are in a few hot tables, and how often full refreshes happen.
- Measure change rate, not table size. A billion-row table that barely changes is cheap under volume pricing; a small table rewritten hourly is not.
- Model the spikes. Month-end closes, marketing sends, and seasonal traffic create bursts. Price the peak month, not the average — that's the invoice that hurts.
- Account for backfills and re-syncs. The initial historical load, and any re-sync after a schema change or outage, can dwarf steady-state volume. Under per-event pricing especially, one backfill can be a month's worth of rows in an afternoon.
- Flag high-churn tables. These are where MAR and per-event pricing diverge most. Identify them up front and price them under both models.
A quick sanity check: take your busiest realistic month, estimate the billable unit for two different models, and compare. If the two numbers are close, the pricing model barely matters and you can choose on features. If they're far apart, the model is the decision.
Questions to ask any vendor
Before you sign, get clear answers — in writing — to these:
- What exactly counts as billable? Inserts, updates, deletes, unchanged re-reads? Get the precise definition of the unit, not the marketing summary.
- Do backfills and re-syncs count? The initial load and recovery syncs are where surprise charges live. Ask whether they're metered like normal volume.
- Are there volume discounts, and where do the tiers kick in? Rates that fall as you grow can flip which vendor is cheapest at your scale.
- What happens on overage? Do you get throttled, auto-upgraded to a pricier tier, or hit with per-unit overage rates? Understand the failure mode before you're in it.
- How predictable is the bill month to month? Ask to see how a comparable customer's usage translated to cost over time — variance matters as much as the rate.
Where Blunox lands
For what it's worth: Blunox Pulse prices on change rows moved, with automatic volume discounts as you scale and no per-seat fees — so adding teammates doesn't change the bill, and heavier usage earns a lower rate rather than a nasty step-up. We think that's the most honest fit for change-data workloads, but the point of this guide stands whatever you choose: know the unit, model your peak month, and read the overage terms. If you want to see the numbers, they're on the pricing page.