Fivetran pricing: MAR, tiers and the cost of unread tables

TL;DR. Fivetran pricing is a volume curve per connection, not per account. On the Standard plan the first million monthly active rows (MAR) on a connection cost $495 per million, while rows above 16 million cost $19.70 per million, 25 times less. That changes which unread tables are worth blocking. In the hypothetical estate priced below, the largest connection holds 84% of the rows nobody reads but only 26% of the money they cost. Rank synced tables by dollars per row at their connection's rate, not by MAR.

Fivetran pricing comes down to one formula from Fivetran's own Service Consumption Table: a base spend plus an incremental rate per million MAR, applied to each connection separately. This post prices that formula at list price, shows the 2026 changes that made bills grow without any new source, and gives the two queries that find synced tables with no reader.

Fivetran prices every connection on its own curve

The rates below are list prices from version 10 of the Service Consumption Table, "effective as of February 1, 2026", read on October 30, 2026. Each connection's monthly cost is "Base Spend per Month + (actual MAR - Monthly Active Row Threshold) * Incremental Spend per Million MAR".

We recomputed each tier's base from the one below it, and the Standard column matches the table to the cent. Fivetran's pricing page gives four median connections that check the formula: Facebook Ads at 34,479 MAR lists at $22.06 and the formula gives $22.07, Marketo at 847,574 MAR lists at $424.54 against $424.55. The one-cent gaps come from Fivetran cutting off the cents instead of rounding them.

Two numbers fall out of the table:

• Plan multipliers are flat. Enterprise costs 1.33 to 1.34 times Standard at every tier, and Business Critical 2.13 to 2.14 times.
• The marginal row price falls 74 times between a small connection ($495 per million) and one above 64 million MAR ($6.72), and keeps falling after that.

Fivetran states the consequence itself: "We apply a usage curve for each connection, meaning the more you use, the less you pay per monthly active row (MAR) per connection" (Monitor and Optimize Usage). Accounts on an annual contract signed before March 1, 2025 are still tiered at the account level until they renew.

What counts as a monthly active row

Fivetran's usage-based pricing docs define MAR as distinct primary keys, counted "separately for each account, destination, connection, table, activation, and activation sync". A row updated 30 times in a month counts once. The rules that decide the bill:

The 2026 pricing updates apply on January 1, 2026 for pay-as-you-go accounts. Annual contracts get the $5 base charge at renewal. Contracts signed after March 1, 2025 also start paying for deletes and history mode at renewal, and contracts signed before that date already did. Transformations are billed apart, by successful model runs: 5,000 free a month, then $0.01 each up to 30,000.

Why the Fivetran bill grows when nobody adds a source

1. New source tables can start syncing on their own. Fivetran treats a new table "like an initial sync", so the backfill is free, but its changes bill every month after that. Whether new tables sync automatically depends on each connection's schema change setting.
2. Deletes became paid MAR. Fivetran says "Previously, deletes did not contribute to paid MAR." A source that purges old rows every night now pays for each purged key.
3. History mode bills repeated updates. Fivetran's own example counts one row that changes three times in a month as 3 MAR.
4. Splitting one source across connections pays the steep tiers twice. Two connections of 3M MAR each cost $840 each, so $1,680. One connection carrying the same 6M MAR costs $1,126. The split costs $554 a month, 49% more, for the same rows.
5. Duplicate connections pay in full. "It is not the connector but the instance of the connection that matters." A staging copy of the Salesforce connection pays its own MAR and its own base charge.

The whole pipeline bill, with orchestration and warehouse compute around the connectors, is broken down in data pipeline cost.

A worked estate: 84% of the unread rows, 26% of the saving

Consider a team on Standard pay-as-you-go with seven connections. The MAR figures and the unread share of each connection are assumptions, chosen to look like a common estate: one large production database and a tail of SaaS sources.

Each saving is the connection's cost minus its cost at the remaining MAR. HubSpot drops from 1.2M to 720,000 MAR, so part of its cut is priced at $170 and part at $495. Jira and Google Sheets are whole connections nobody reads, so pausing them also removes the $5 base.

The Usage tab shows MAR per connection and table, and MAR points you at the wrong connection. The 10 million unread Postgres rows are worth $197. The 1.85 million unread rows on the six smaller connections are worth $569.24. A table on a connection under 1M MAR is worth blocking at a fraction of the row count that justifies a cut on the big one.

Find the synced tables nobody reads with two queries

The Fivetran Platform Connector writes its metadata to your destination for free; its MAR is free, though queries on it use warehouse compute. Its INCREMENTAL_MAR table holds "Daily Monthly Active Rows (MAR) consumption per connection, schema, and table", with a free_type column that separates PAID rows from free ones (table reference).

On Snowflake, join last month's paid MAR to 90 days of ACCESS_HISTORY. Use base_objects_accessed: Snowflake's access history guide shows that a query on a view records the base table under it there, so a dashboard that reads a view still counts as a reader:

with mar as (
  select connection_name, schema_name, table_name,
         sum(incremental_rows) as paid_mar
  from fivetran_metadata.incremental_mar          -- your Platform Connector schema
  where free_type = 'PAID'
    and measured_date >= date_trunc('month', dateadd(month, -1, current_date))
    and measured_date <  date_trunc('month', current_date)
  group by 1, 2, 3
),
reads as (
  select upper(obj.value:"objectName"::string) as object_name,
         count(distinct ah.user_name)          as readers,
         max(ah.query_start_time)              as last_read
  from snowflake.account_usage.access_history ah,
       lateral flatten(input => ah.base_objects_accessed) obj
  where ah.query_start_time >= dateadd(day, -90, current_timestamp())
    and obj.value:"objectDomain"::string = 'Table'
    and ah.user_name not in ('FIVETRAN_USER', 'DBT_USER')  -- your loader and transform users
  group by 1
)
select m.connection_name, m.schema_name, m.table_name, m.paid_mar
from mar m
left join reads r
  on r.object_name = upper('RAW.' || m.schema_name || '.' || m.table_name)  -- your destination database
where r.object_name is null
order by m.paid_mar desc;

Then price each table at its connection's marginal rate from the table above, or recompute the connection's cost without it. Sort by dollars, not by paid_mar.

Four limits on this query:

1. ACCESS_HISTORY needs Enterprise Edition or higher, keeps 365 days, and Snowflake says its latency "may be up to 180 minutes".
2. A table read only by your transformation user is not proven useful. Excluding that user marks raw tables that feed dbt models as unread, so check whether anyone reads the models they feed before you block them.
3. On BigQuery, use referenced_tables in INFORMATION_SCHEMA.JOBS: its history covers 180 days, and the column is "Only populated for query jobs that are not cache hits".
4. Some readers never touch the warehouse. A table may be exported, shared or kept for audit. No reader in 90 days is a reason to ask its owner, not proof.

Cut the Fivetran bill in dollar order

1. Pause dead connections. Fivetran's own advice: "if you have connections with a low usage that don't bring any analytical value, it may be best to pause the connections." Each removes its $5 base and its whole curve.
2. Block unread tables on small connections first. Blocking schemas or tables reduces MAR, where the connector supports it, at up to $495 per million rows.
3. Turn history mode off where nobody queries history. Soft delete mode keeps deletes visible, and Fivetran says its "Repeated updates do not count towards paid MAR".
4. Merge split connections to one source. In the 6M example above, that is $554 a month for no change in data.
5. Leave sync frequency alone. Fivetran says frequency "makes no difference to your monthly active rows". What a sync costs on the warehouse side is a separate question, covered in Snowflake cost optimization.

Annual contract, pay-as-you-go or an ELA

Pay-as-you-go bills list price monthly in arrears with no commitment. Annual contracts start at a $12,000 minimum and get a "5% built-in discount", rising on Standard to 22.6% or more above $145,340 of annual list price (Plans and Billing). Enterprise License Agreements fix the yearly price with no consumption limit. For customers who want predictability, Fivetran says it estimates the planned workload on consumption pricing "and offer an ELA at a premium to this price".

So the choice is about forecast error. An annual contract is cheaper if your MAR is stable. An ELA only pays off if your rows grow faster than the premium. Cleaning unread tables before you sign lowers the list price the discount applies to.

The case for leaving unread tables alone

The strongest objection: in our estate the cleanup saves $766.24 a month, 18.5% of the Fivetran line. A day of an engineer's time, and one wrong block that breaks a quarterly report, can cost more. Fivetran's rows also get cheaper as you add them, so blocking tables on a large connection buys little.

That holds for the big connection, which is why it ranks last here. It does not hold for the tail: the six small connections give $569.24 of the saving from 16% of the unread rows. Part of the cost of an unread table also sits outside Fivetran: the warehouse compute to load its rows, and any models rebuilt on top of it.

The limits of this post: Standard list prices from the table effective February 1, 2026; annual discounts and negotiated rates change every figure. The estate and its unread shares are hypothetical. We did not price activations, transformations above the free tier, Hybrid Deployment or destination costs, and we did not test the SQL against a live Fivetran account.

Where Datapace fits

Pricing a Fivetran cleanup takes three things that live in three places: paid MAR by table in the Platform Connector, readers in the warehouse's access history, and the rate curve in a legal document. Datapace is building one map of your data estate with usage and cost attached, and agents that propose changes as pull requests your team reviews and merges. To see what the rest of the warehouse bill adds on top of ingestion, read data warehouse cost.

Sources

1. Fivetran, Service Consumption Table, V.10, effective February 1, 2026 (the document rendered at fivetran.com/legal/service-consumption-table), read October 30, 2026 (connection MAR rates and base spend per plan, cost formula, transformation rates).
2. Fivetran, Pricing (median connection pricing example, plans).
3. Fivetran, Usage-Based Pricing (MAR definition, free MAR, connection base charge, multiple connections, new tables, history mode, data blocking).
4. Fivetran, 2026 Pricing Updates (minimum charge, deletes, history mode, soft delete mode).
5. Fivetran, Monitor and Optimize Usage (connection-level curve, sync frequency, blocking, pausing).
6. Fivetran, Plans and Billing (annual discounts, minimums, pay-as-you-go).
7. Fivetran, Fivetran Platform Connector and table reference (INCREMENTAL_MAR).
8. Snowflake, ACCESS_HISTORY view.
9. Google Cloud, INFORMATION_SCHEMA.JOBS view.