Why Did My MAR Usage Increase After I Applied a Row Filter?

Question

I applied a row filter to a table, but instead of reducing my Monthly Active Rows (MAR), my paid MAR usage went up. Why?

Environment

All connectors

Answer

Applying or changing a row filter triggers a table re-sync, which writes a reconciliation record to your destination for every row that no longer matches the filter. What that record looks like depends on your sync mode:

• Soft delete mode (default): the row is marked _fivetran_deleted = TRUE.
• History mode: the active version is closed (_fivetran_active = FALSE, _fivetran_end populated) and a new version is written.
• Live mode: the row is hard-deleted from the destination.

In all cases, each write counts toward paid MAR for the calendar month in which the re-sync completes.

The usage is real, not a display error. It reflects the cost of reconciling your destination against the new filter in a single pass.

On the current pricing plan (post-March 2025)

Each affected row is reconciled once when the re-sync runs. That write counts toward MAR in the month the re-sync completes. In subsequent months, repeated source deletions of the same excluded row are not counted toward MAR again.

The spike is therefore a one-time cost per affected row, scoped to the calendar month in which the re-sync completes.

On the legacy pricing plan (pre-March 2025)

On the legacy plan, the spike can recur. A row that was previously soft-deleted and is then re-detected as deleted in a later sync is counted toward MAR again. This means the same excluded row can generate a MAR charge in multiple months, not just the month you applied the filter.

For full details of how MAR was counted on the legacy plan, see Pre-March 2025 Pricing.

Why rows deleted at the source also count toward paid MAR

Row filters evaluate column values, but source DELETE events typically carry only the primary key - there are no column values to check against the filter condition. As a result, Fivetran passes all source-side deletions through to your destination unfiltered. A row that was deleted at the source but did not match your filter still generates a destination write and counts toward MAR. This applies on all pricing plans.

How to minimize the impact

• Apply your filter before the initial sync. If you set up a row filter when you create the connection, excluded rows are never written to your destination in the first place. There are no existing rows to reconcile, so there is no spike.
• Avoid editing filters on large tables mid-stream. Each filter change triggers a re-sync and reconciles every newly excluded row in that sync.

For information about the pricing estimate change you may see on the Fivetran dashboard after applying a row filter, see Why Did My Pricing Estimate Increase After I Applied Row Filters?