Fivetran re-import tables bill only changed rows toward MAR; initial sync is free

Fivetran re-import tables bill only changed rows toward MAR; initial sync is free

TL;DR

Never cost re-import connectors from rows_synced; only new and changed rows count toward MAR, and initial-sync rows are free. When reconciling usage, expect a re-import connector's synced row count to dwarf its MAR; that is normal, not a bug. If MAR spikes on a re-import connector, look for a surge in actually-changed rows (or a schema change triggering a backfill) rather than blaming the sync strategy.

Use this when you run into the situation in the title.

When not to use this skill: unrelated tasks. It covers only the procedure above.

Compatibility

The steps above apply to the commands named in them. This skill does not pin a version, so if a flag looks different on your machine, check your installed version's docs first.

Details

Context: Official Fivetran docs (How Do Re-Imported Tables Count towards MAR): documents that for connections whose sync strategy re-imports tables in full every sync, Fivetran applies the same logic as incremental tables and only activates changed rows. Example: a re-import table with 100 unchanged rows syncs all 100 but MAR is zero; when 20 rows are new and 20 changed, MAR is 40. Any re-imported table included in an initial sync counts towards free MAR on the day of the initial sync. Agents that cost Fivetran from rows synced overstate MAR massively on re-import connectors.

Source: Official Fivetran docs (How Do Re-Imported Tables Count towards MAR): documents that for connections whose sync strategy re-imports tables in full every sync, Fivetran applies the same logic as incremental tables and only activates changed rows. Example: a re-import table with 100 unchanged rows syncs all 100 but MAR is zero; when 20 rows are new and 20 changed, MAR is 40. Any re-imported table included in an initial sync counts towards free MAR on the day of the initial sync. Agents that cost Fivetran from rows synced overstate MAR massively on re-import connectors.

Verified resolution: Never cost re-import connectors from rows_synced; only new and changed rows count toward MAR, and initial-sync rows are free. When reconciling usage, expect a re-import connector's synced row count to dwarf its MAR; that is normal, not a bug. If MAR spikes on a re-import connector, look for a surge in actually-changed rows (or a schema change triggering a backfill) rather than blaming the sync strategy.

Source URL: https://fivetran.com/docs/core-concepts/usage-based-pricing/troubleshooting/reimported-tables