Usage-Based Pricing

Fivetran’s pricing model involves four basic principles:

• Pricing is usage-based. You are charged based on what you use each month.
• Your connection usage is measured in Monthly Active Rows (MAR). MAR are unique identifiers, or primary keys, that we use to track transfers from your source system to your destination each month. These keys are counted separately for each account, destination, connection, and table. Once a row is active, it is only counted once per month - no matter how many updates are made that month.
• Your transformation usage is measured in monthly model runs. Monthly model runs is the total number of models successfully executed as part of your transformation jobs in a given month.
• You can choose which pricing plan fits your requirements. See Billing and Plans for more information.

Monthly Active Rows

MAR is the number of distinct primary keys synced from the source system to your destination in a given calendar month. A primary key is a unique identifier that specifies a distinct row within a table. We separately count primary keys by account, destination, connection, and table. If a primary key is not available, we create a synthetic (hashed) primary key to ensure consistency. Fivetran uses a hash sampling re-sync detection algorithm to detect and classify row changes.

We only count a row once per month, even if it syncs multiple times. It doesn’t matter how many times a row is updated in a month; you don’t pay multiple times for updates on the same row in the same month. For example, if we sync a distinct primary key more than once in a month, then the distinct primary key counts as only a single MAR.

Monthly active rows are similar to total monthly synced rows but are less prone to variation and outliers. For example, a distinct primary key synced 30 times during a month counts as one MAR. Row-based pricing models, such as monthly synced rows, would charge you multiple times in that situation. Fivetran does not.

To understand what monthly active rows mean, and how they differ from monthly synced rows, consider the following simplified example:

Suppose you have a small table with a primary key id and one attribute, counter:

You update counter from 3 to 4 in row c:

This operation generates 1 active row. Now suppose you update the same counter again in the same month:

This is still just 1 active row for this month. On the other hand, if you update row a, then you have 2 active rows:

We sync most connections using incremental updates where we only update the new or updated rows each sync. Thus, you only pay for a subset of the data in the source every month. What percentage of a table or a connection is imported per month depends on how you use your source system. For example:

• If you opt to modify only new records, we import only a small percentage of the table or connection per month that causes a small percentage of the tables to have MAR.
• If you opt to modify years-old historical records every sync, we re-import the complete source data that may cause a very high percentage of the tables to have MAR depending on the number of changes in your source system.

MAR types

Learn about the different types of MAR that exist to better understand your usage.

Historical MAR

Historical MAR represents data that already exists in the source or was synced when the table or connection was created.

Examples of historical MAR include:

• Initial table syncs
• Table schema changes that lead to a full table re-sync (for example, new added columns)
• Manually triggered re-syncs
• Data added during the first sync after a new account or project is added
• Periodic re-syncs of additional data to avoid data integrity issues
• Source-specific data integrity issues that require re-syncs
• Migration syncs
• Bug fixes that require re-syncs

Free MAR

Free MAR represents rows that are synced but do not count towards paid MAR. The following counts towards free MAR:

• Initial syncs
• Connection trials
• Private preview connectors (excluding destinations)
• Fivetran system tables
• Fivetran Platform connector
• Re-syncs
• HVR Troubleshooting Window
• Accounts with a legacy pricing plan
• Free plan
• Promotions

Incremental MAR

Incremental MAR represents new or updated data in the source since the last sync.

Examples of incremental MAR include:

• Overlapping incremental syncs
• Changes in re-imported table syncs
• Reporting connector rollback syncs that occur during a conversion window

Understand your MAR usage

Learn how operations in your Fivetran account impact your MAR usage.

To learn how to monitor and optimize your MAR usage, see our Monitor and Optimize Usage documentation.

Connections

Learn how connections can affect your MAR usage in specific circumstances.

New connections

Every new connection you create has 14 days of use at no cost.

Multiple connections based on the same connector

Each connection in your account contributes towards your monthly active rows. It is not the connector but the instance of the connection that matters. Even if the connections sync the same data from the same source (with the same primary keys), they contribute separately to your MAR.

Same source, multiple destinations

If you have two or more connections of the same type that sync from one source to multiple destinations, we count each connection’s active monthly rows separately. For example, if you have two Salesforce connections, where one syncs to your staging destination and the other to production, we count the MAR of the connections separately. The sum of rows synced through each connection counts towards your MAR.

Release phases

Every connection based on a Private Preview connector is free, excluding destinations. We charge for connections when the associated connector is in Beta or Generally Available, and pricing varies on functionality. See our core concepts documentation for more information.

Syncs

Learn how different sync types affect your MAR usage.

Initial syncs

Initial syncs don't incur a cost for the historical data they sync, but tracked incremental updates may count towards paid MAR outside the connection free trial period.

Re-syncs

In the following scenarios, re-syncs are free:

• Historical data from adding a column
• Unchanged rows in re-import tables
• History mode unchanged rows
• Post-trial MAR that was already seen in the trial
• All other historical syncs

Rollback syncs

If your connection performs a rollback sync as part of its sync strategy, the sync may fetch additional data from the previous month. We consider these past records as new unique records for the current month, and these rows count towards your MAR.

Priority-first syncs

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 to a connection that supports priority-first sync when an incremental sync is running, it impacts your MAR usage.

Phantom updates

In some rare scenarios, a connection is created without an initial sync. In such scenarios, the source may attempt to update rows that do not exist in the destination. We define these updates as phantom updates. Phantom updates are not visible in the destination, but they contribute to MAR since we capture these updates.

For example, consider that you have a table TARGET in the source database, with column id as its primary key. Now, consider that you update the value of the id column. In the next sync, we see that column for the first time due to an incomplete initial sync, but we also see the update operation. During this sync, we mark it as an update and this row counts towards MAR.

Tables and schemas

Learn how table and schema updates affect your MAR usage.

New tables

New tables are treated like an initial sync. See our MAR for new tables troubleshooting article to learn more.

New columns

When you sync a new column of an existing table, that insert doesn't count towards MAR. When adding a new column triggers a table refresh, it still doesn't count towards MAR if there are no data changes. However, if any of the re-synced rows have changes, we detect those and count these changes towards paid MAR.

Columns with null values

When a connection syncs a null value for a column and then the value changes in the next sync, that change counts towards MAR.

On the other hand, if a column doesn't have any value at all, and then your connection syncs a value for that column during the next sync, it doesn't count towards MAR.

Automated schema migrations

When we automatically add a column to a connector schema as part of an automated schema migration, rows in the table that are backfilled with data don't count towards MAR.

Primary key data type changes

If the data type of primary key changes, it doesn't affect your MAR.

Similarly, in a table without a primary key, if the data type of columns from which we generate synthetic (hash) primary key changes, it doesn't affect your MAR.

Tables without a primary key

If a table doesn’t have a primary key, we create a synthetic (hash) primary key. The synthetic primary key is a hash of values of the columns defined for that table, so if those columns change, the primary key changes. We calculate the MAR for these tables based on their synthetic primary keys. The composition of this primary key differs by source.

In a table without a primary key, adding or removing columns that we use to generate the synthetic primary key does affect MAR. Each row in the table counts towards MAR.

Fivetran system tables

The following connector-specific system tables count towards free MAR:

• FIVETRAN_QUERY
• FIVETRAN_API_CALL
• FIVETRAN_FORMULA
• FIVETRAN_FORMULA_MODEL

History mode tables

Every time a record's value in a source table with history mode enabled changes, we insert a new row in the destination table. This new row counts towards MAR only when there is changed data, and your usage depends on the number of changes.

Re-import tables

We re-import tables in full during every sync as part of the sync strategy for some of your connections. During a re-import sync, we apply the same logic as for incremental tables that only activate changed rows.

For example, let's say that you have a re-import table with 100 rows from the previous month with zero changes. Fivetran will sync all 100 rows but considering there weren't any changes, it won't count towards MAR. Then, there is another sync 24 hours later and there are 20 new rows. During this second sync, Fivetran re-imports the full 120 rows but the MAR usage is just 20.

Data blocking

You can block specific columns and tables from replicating to your destination. However, you can't block primary key columns. Updates to a blocked column that is not a primary key column in your source table don't count toward MAR. We exclude blocked columns from your syncs.

Deletes in the source

If a connector supports the Capture Deletes feature, and you delete data from your source, it does not count towards MAR usage. We soft delete the corresponding data in your destination by setting the system column _fivetran_deleted to TRUE.

Deletes in the destination

If you delete data in your destination and later sync it again from your source, it counts towards your MAR.

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
• Individual connection 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, but only from the incremental data from that new source account.

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, with 10 unchanged rows and 5 inserts.
3. Last sync (May 31st) – file has 16 rows, with 8 unchanged rows, 2 changed rows, and 6 inserts. The 2 changed rows and 6 inserts count toward paid MAR.

The connection synced 16 rows in total. However, only the 2 changed rows and 6 inserts count toward MAR.

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).

Fivetran Platform Connector

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

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.

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 if changes are detected.
• We re-import the tables that we can’t incrementally update. When we re-import a table, we count only changed rows as paid MAR.
• 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.

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.

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 information on Sailthru's API limits.

Transformations

Transformation usage does not count towards monthly active rows (MAR). Instead, we measure transformation usage in monthly model runs. We only count successful monthly model runs as usage.

Each month, we offer 5,000 free model runs. Once your usage goes past 5,000 monthly model runs, we start charging for transformations usage. Additionally, the higher your paid usage is, the lower is the price per model run. See our Transformations Pricing and Transformations Pricing FAQ documentation for more details and instructions on how to monitor and optimize your monthly model runs consumption.