Destination-Based Pricing vs Row-Based Pricing for Data Export

How row-based pricing works mechanically, and what it bills

Data export pricing splits into two camps that measure entirely different things: row-based models charge for the volume of data that moves or changes, and destination-based models charge for where that data lands. Most teams pick one without realizing there was a choice to make. The distinction sounds like accounting trivia until a bill arrives well over budget, and by then the roadmap has usually already been built on assumptions that no longer hold.

Row-based pricing charges for the number of rows added, changed, or deleted in a destination over a billing period. The market term is Monthly Active Rows, or MAR, and it has become the dominant meter in the ETL/ELT space. Here's the mechanical detail that trips people up: a row counts once per change, so the meter tracks how fast the underlying data changes, not how often a sync job runs. Sync every five minutes or once a day, the MAR total stays the same, because the bill follows row edits, not polling frequency.

Billing is additive across sources, not blended, and this is where most cost estimates fall apart before the contract even gets signed. A pipeline pulling 500,000 changed rows from Salesforce and 300,000 from Google Ads doesn't get billed as 800,000 combined rows against one rate. It gets billed as two separate MAR charges, each hitting its own tier threshold on its own terms. A team estimating cost by summing total row volume across all sources will underestimate what it owes, every single time, because the vendor's math and the customer's math were never the same math to begin with.

The tier structure typically runs Free, Standard, Enterprise, and Business Critical, with no separate "Starter" tier despite what some buying guides suggest. Standard starts around $500, Enterprise around $667, Business Critical around $1,067, and those are entry rates, not ceilings. Real workloads in the 5 million to upper-range MAR band commonly run anywhere from $2,500 to more than $26,000 a month, depending on tier and connector count. Every active connector also carries a minimum charge of $5, regardless of how much data flows through it. Adding a dozen low-volume connectors for edge-case sources causes that minimum to add up fast, before a single meaningful row gets counted.

The 2025–2026 changes that turned row-based pricing from a planning nuisance into a budget shock

Teams don't abandon a pricing model because the pricing page looked confusing on day one. They abandon it because the model quietly stops matching how they actually use the product, and the bill eventually forces the conversation. That's the pattern that played out in the row-based market over the past year, and none of it was subtle.

Since March 2025, Fivetran shifted to billing MAR per connector rather than in aggregate. That sounds like a technical footnote, but it's among the changes most responsible for the cost increases teams are now dealing with. Then, starting January 2026, what counts as a "row" expanded further: deletes count now, history-mode rows count, and every active connector carries that $5 minimum regardless of volume. None of these changes required a customer to move more data. They just changed what got measured, and the combined effect pushed many bills 40% to 70% higher than the prior year, with no change in underlying usage.

Before these changes, a customer syncing from Salesforce and Google Ads into one warehouse got a single combined MAR tally, priced against one tier. After the changes, that same customer gets two separate tallies, each priced independently, each capable of crossing into a higher tier on its own. The math doesn't just go up. It goes up in a way that's structurally harder to predict from the outside, because tier boundaries interact differently once sources stop pooling together.

This landed in a budget environment with little room to absorb it. Over the past 12 months, 61% of organizations report cutting projects specifically because of unplanned SaaS cost increases. Row-based billing changes didn't create that environment, but they landed squarely inside it; for a data team already fighting for headcount, an unplanned jump on a pipeline bill gets a renewal escalated to a VP.

What destination-based pricing charges for

Destination-based pricing charges according to the number and type of endpoints receiving data. A warehouse counts as a destination. A database counts as a destination. An object storage bucket counts as a destination. Row count flowing into any of them is, for pricing purposes, beside the point. That's the whole design.

The consequence is stark: a customer syncing 50 million rows into a single Snowflake instance pays the same as a customer syncing 5 million rows into that same instance, provided both are paying for one destination. Volume stops being the variable that determines cost. Destination count and destination type take its place, and that swap is the entire argument for the model.

The structure exists because it tracks something closer to the vendor's actual cost to serve. Each new destination type, whether a new warehouse, a new database engine, or a new cloud storage format, needs its own connector logic, its own schema mapping, its own credential handling, its own security review. Row volume within an existing destination doesn't generate that kind of engineering work. Destination count does, which makes it the more honest proxy for what the vendor actually spends.

The 2026 destination landscape breaks into a few recognizable categories. Cloud warehouses (Snowflake, BigQuery, Amazon Redshift, Azure Synapse or Microsoft Fabric, Databricks) form the primary tier most vendors price around. Databases typically get bundled at the same rate as warehouses, or get their own adjacent tier. Object storage, Amazon S3, Azure Blob, Google Cloud Storage, has increasingly become its own distinct category as more teams adopt lakehouse architectures instead of warehouse-only setups. Multi-destination fan-out is becoming a real pricing wrinkle too: platforms like BigQuery Omni can now query data sitting in AWS S3 or Azure Blob without physically moving it, which forces destination-based models to account for cross-cloud querying patterns that don't fit a single-destination assumption.

Where each model works well and breaks down under real workload conditions

Row-based pricing earns its popularity honestly at the low end, and only at the low end. A small team running one or two connectors with a stable, low change rate pays close to nothing, because the meter genuinely reflects light usage. That low barrier to entry explains a good chunk of why usage-based pricing has spread as fast as it has. It also cuts the other way for the vendor: a customer's row volume dropping sharply is an early churn signal that appears in the data before a support ticket ever gets filed.

The failure mode occurs under the exact conditions that produced the early success. As a company grows and more internal teams want fresher data, more frequent syncs, more connectors, the row-based bill grows right along with it, but not in proportion to what it's actually costing the vendor to serve that customer. Nested JSON and volatile upstream schemas make this worse, since a single schema change can inflate row counts in ways no customer action caused and no customer can control. Layering the per-connector minimum on top turns connector sprawl, a normal consequence of a company adopting more tools, into a compounding cost center instead of a sign the platform is being adopted well. Forecasting gets harder exactly when the business needs it to get easier. Past the pilot stage, that's the whole case against relying on row-based pricing.

Destination-based pricing makes costs knowable before a single row moves, and that predictability is the model's real selling point. A finance team can commit to a number without needing a data engineer to translate the assumptions first. Data-intensive workloads stop being penalized for being data-intensive: a team running 100 million rows into one destination pays the same as a team running 10 million into that same destination, so growth in data volume, usually a sign the product is working, doesn't get treated as a cost event. The incentive alignment holds up on inspection, too. Each new destination type requires its own connector logic, schema mapping, and security review, so destination count is a closer proxy for the vendor's engineering work than row volume is, and it roughly tracks where customers gain new capability.

The limitation cuts the other direction. A vendor with one customer running an enormous, data-heavy workload into a single destination may find that customer costs far more to serve than the flat destination rate captures, and the pricing model has no built-in way to correct for it. Flat-rate structures also cap the upsell motion, since there's no natural expansion lever tied to usage growth unless the vendor layers in a second meter for something else. Destination-based pricing works best when customer workloads are roughly uniform, and it strains the moment one customer's single destination is doing the work of ten typical customers.

Neither model is neutral. Row-based pricing is the right call only inside a narrow band: small, stable, low-connector-count workloads where the meter tracks real usage. Outside that band, it becomes a tax on growth. Destination-based pricing is the more defensible default for anything past pilot scale, precisely because it stops punishing the thing every data team is actually trying to do, which is move more data, more often, without wondering if this is the sync that trips a tier.

How the pricing model choice affects teams embedding data export into their own products

Any SaaS company that offers data export as a feature to its own customers inherits whatever pricing model underlies its data connectivity layer, and it usually has to translate that model into something it re-exposes downstream. That inheritance is where the real operational risk lives, since the company embedding the feature rarely gets to renegotiate the meter it's stuck with.

Row-based billing creates a specific trap here. If the underlying vendor charges by MAR, the SaaS company absorbs all the volatility of its own customers' data activity. A spike in one customer's usage, triggered by something entirely outside the SaaS company's control, becomes an unplanned cost the company has to eat or pass along awkwardly after the fact. This is structurally the same problem embedded analytics products run into with per-viewer pricing: embed a dashboard into a product used by thousands of end users, and the pricing scales linearly with exactly the kind of adoption success the product team is supposed to be chasing. Credit-based or consumption-based pricing on embedded tools produces the identical failure. A burst of customer engagement turns into a bill nobody budgeted for.

Support during integration matters just as much as the pricing structure itself, since onboarding friction and integration complexity consistently shape whether a software purchase delivers on its promise. Pricing legibility is part of that support story: a model a customer can explain to their own finance team in one sentence is worth more than a marginally cheaper model that requires a spreadsheet to forecast. The destination landscape those customers ship into keeps fragmenting, too, with organizations now running an average of 106 different SaaS tools, so the export feature a product team ships has to reach an increasingly varied set of endpoints. That fragmentation is why destination-count pricing is the more operationally honest choice for embedded use cases. It scales with the thing that's actually growing, destination diversity, rather than with row counts that spike for reasons no one can fully explain after the fact.

What to ask before choosing or switching a data export pricing model

The switch decision has to be forward-looking, because teams change pricing models when the model stops matching the workload, not when the sales page first gets read. The useful questions are about where the workload is headed.

Row-based pricing holds up when connector count is small and stable, when the data change rate is predictable and narrow in scope, and when the team is still in a pilot phase where low upfront cost outweighs the need for an accurate long-term forecast. It also assumes there's engineering capacity available to actually watch the row-count meters and tune sync schedules to keep costs in check. That's a real ongoing resourcing commitment, not a one-time setup task, and teams that skip it are the ones who get surprised by the bill.

Destination-based pricing fits better when data export ships as a product feature rather than gets managed as internal infrastructure, when customers connect to multiple warehouse or storage targets instead of one, and when data volume grows faster than anyone can forecast by hand. It's also the better fit when finance needs a committed number before the quarter starts, and increasingly, when AI agents or automated workflows consume synced data in volumes that are hard to predict in advance, since those workloads tend to generate row-count volatility severe enough to break row-based forecasting.

Before signing or renewing any row-based contract, get a short list of questions answered in writing, not assumed. Are deletes counted toward the meter? Is billing additive across sources or blended? Are there minimum charges per connector regardless of volume? Does nested or structured data inflate the row count on its own, independent of actual business activity? Are transformation runs billed on a separate meter entirely, layered on top of the row charges? Every one of those answers changes the real cost of the contract, and none of them appear on a standard pricing page.