MAR Management

Understand how different Fivetran connectors affect MAR.

TIP: For database connections, you can use your database's total row count to roughly estimate your MAR. Learn how in our Identify Total Row Count for Databases documentation.

Connector-specific functional differences

We calculate MAR in the same way for all our connectors. However, MAR calculations can vary due to significant differences in:

• API capabilities
• Connector configuration
• Source configuration
• Access management
• Underlying data models
• Raw data formats

Therefore, some connection types require tailored sync strategies.

Ad reporting connectors

We do not exclude historical syncs when you add a new source account to the connectors listed below. If you add a new source account to the sync when the incremental sync is running, your MAR usage will increase.

• Adobe Analytics
• Adobe Analytics Data Feed
• Adjust
• AdRoll
• Amazon Ads
• Amazon Selling Partner
• Amplitude
• Apple Search Ads
• Braintree
• Criteo
• Eloqua
• Facebook Ads
• Facebook Pages
• Google Ad Manager
• Google Ads
• Google Analytics 4
• Google Display & Video 360
• Google Search Ads 360
• Google Search Console
• Help Scout
• HubSpot
• Instagram Business
• Iterable
• LinkedIn Ad Analytics
• LinkedIn Company Pages
• Marketo
• Microsoft Advertising (formerly Bing Ads)
• Outbrain
• Pinterest Ads
• Recharge
• Salesforce Marketing Cloud
• Shopify
• Snapchat Ads
• Taboola
• TikTok Ads
• Twitter Ads
• Yahoo DSP
• YouTube Analytics
• Zendesk

File connectors

File sources don't provide change-tracking data to help us determine if specific rows have been updated in the source. As a result, every time you schedule a sync, we re-sync all the rows from files that were modified. We calculate MAR for a file based on the greatest number of rows we sync from that file during any sync in a given month. For file connectors, we add three columns as composite primary keys for a table.

For example, let's assume that you add a new file with 10 rows to your connection's configured location:

1. Initial sync (May 1st) – file has 10 rows
2. Next sync (May 15th) – file has 15 rows
3. Last sync (May 31st) – file has 16 rows

The greatest number of rows ever synced for the file during May is 16, so the MAR for that month is 16.

If you configure the modified file merge option to append_only, all rows will count towards MAR. So, in the previous example, the MAR would be 41 (Free MAR 10 + Paid MAR 31).

NOTE: For our Amazon S3, Azure Blob Storage, Google Cloud Storage, and SFTP connectors, we capture a file's last modified date. This lets us determine if a file has been updated in the source. When we detect an update in the source, we re-sync the entire file. That means each row in the source counts towards monthly active rows. However, if the file is updated multiple times in a month, its rows only count toward monthly active rows once.

IMPORTANT: For our Magic Folder connectors, we use the last modified date of the files to detect changes in the files of your cloud folder. For more information about the sync strategy of Magic Folder connectors, see our documentation.

Fivetran Platform Connector

The MAR that the Fivetran Platform Connector generates is free. You can track your free MAR in the Usage tab.

NOTE: Using this connector may incur costs in your destination if your service provider charges for compute usage. Learn more in our destination costs documentation.

Asana

Due to how the Asana API uses sync tokens, you may observe periodic increases in MAR consumption. Read our Asana sync strategy documentation for more information.

HubSpot

Our HubSpot connector re-syncs several tables every day because the HubSpot API does not offer a mechanism to capture deletes. By re-syncing these tables, we can infer deletes. These re-syncs increase consumption for HubSpot.

See our HubSpot MAR Management article for more details.

Iterable

The following tables are append-only:

• EVENT
• EVENT_EXTENSION
• USER_HISTORY
• USER_UNSUBSCRIBED_CHANNEL_HISTORY
• USER_UNSUBSCRIBED_MESSAGE_TYPE_HISTORY
• USER_DEVICE_HISTORY
• LIST_USER_HISTORY
• CAMPAIGN_METRICS

For these tables, we capture events from Iterable using webhooks and the Events API, then write them to the destination. We never overwrite existing events in the destination unless a re-sync is triggered. During a re-sync, we get the same events from the API again and overwrite the events in the destination.

We sync the remaining tables using non-incremental endpoints, so we re-import them during every sync.

MongoDB

We perform an automatic full re-sync when we see that the oldest oplog entry is newer than expected.

See our MongoDB MAR Management article for more details.

NetSuite Suite Analytics

We use a hybrid approach to determine the overall MAR for NetSuite:

• We incrementally update tables with a modified timestamp. The incrementally updated rows count towards monthly active rows.
• We use a checksum to capture deletes incrementally. The data ranges of each table where changes are occurring count towards monthly active rows.
• We re-import the tables that we can’t incrementally update. As a result, the entire re-imported table counts towards monthly active rows. This may lead to the MAR being higher than the row count in the destination.
• We only sync new records for SYSTEM_NOTES and SYSTEM_NOTES_CUSTOM tables. We consider only the records created in the calendar month as monthly active rows.

NOTE: We update the TRANSACTIONS and TRANSACTION_LINES tables incrementally. We don't recommend frequent updates of the historical records for the TRANSACTION_LINES table, as this significantly increases the count of monthly active rows.

Oracle

When you add a new column to an Oracle table that we are syncing, we always trigger a table re-sync. Changes to the table structure interfere with LogMiner and force us to re-sync the table.

PostgreSQL

Using XMIN instead of WAL in your PostgreSQL connector has a negligible impact on your MAR consumption. XMIN does not capture deletes, leading to slightly lower MAR in comparison.

See our PostgreSQL MAR Management article for more details.

Sailthru

Due to Sailthru API limitations, you may see a sudden increase in MAR at the start of the month. Read our Sailthru sync strategy documentation for more info on Sailthru's API limits.

Priority-first sync

Priority-first syncs fetch your most recent data first so that it's quickly ready for you to use. If you add a new source account in the setup form of the following connectors when an incremental sync is running, it impacts your MAR usage:

IMPORTANT: Connectors that support priority-first sync activate a connection's free trial period as soon as a priority-first sync is initiated and the system detects incremental data.

Additional MAR management resources

See connector-specific articles linked below for more MAR management best practices:

• Google Sheets
• HubSpot
• Jira
• LinkedIn Ads
• Mailchimp
• Marketo
• Microsoft Advertising
• Mixpanel
• MongoDB
• MySQL
• PostgreSQL
• SQL Server
• Webhooks
• Zendesk Support