Consumption-Based Pricing
In this document, you will learn how monthly active rows (MAR) are calculated, how to track your MAR, and how to optimize your usage.
Our pricing model is based on consumption. Each month, we calculate your consumption of credits based on your monthly active rows across all connectors and destinations in your account.
You can either purchase a block of credits meant to last a year or add a credit card to your account and pay as you go.
You can use any Fivetran connectors you want and add or remove connectors over time. You can likewise add or remove destinations. Your credits will be consumed based on your MAR, with no difference between connectors. Connectors will use varying MAR based on the data that is being added or changed in the source system and the sync strategy that Fivetran has selected.
As your monthly usage increases, the cost per row declines automatically, so if your usage is higher than you expected, you'll get a better rate without having to renegotiate. Usage can vary depending on the number of re-syncs initiated or connectors added or removed during that period.
Determining MAR
We calculate your monthly active rows based on the number of distinct primary keys we sync across all the connectors in your account. We only count a row once per calendar month, even if it syncs multiple times.
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:
| id | counter |
|---|---|
| a | 1 |
| b | 2 |
| c | 3 |
Suppose you update counter from 3 to 4 in row c:
| id | counter |
|---|---|
| a | 1 |
| b | 2 |
| c | 3 |
| c | 4 |
This operation generates 1 active row. Now suppose you update the same counter again in the same month:
| id | counter |
|---|---|
| a | 1 |
| b | 2 |
| c | 3 |
| c | 4 |
| c | 5 |
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:
| id | counter |
|---|---|
| a | 1 |
| a | 10 |
| b | 2 |
| c | 3 |
| c | 4 |
| c | 5 |
With MAR-based pricing, you don’t pay multiple times for updates on the same row in the same month. It doesn’t matter how many times a row is updated in a month. Other popular row-based pricing models, such as monthly synced rows, would charge you multiple times in that situation. Fivetran does not.
We sync most connectors using incremental updates. Only new or updated rows are updated during each sync. Thus, you only pay for a subset of the data in the source every month. What percentage of a table or a connector is imported per month depends on how you use your source system. Some customers modify only new records. Then, only a small percentage of the table or connector is imported per month. Other customers modify years-old records every sync. That causes a very high percentage of the tables to be monthly active rows.
Edge cases
Initial syncs
Initial syncs do not count towards monthly active rows. That means when you first create a connector and sync all the historical data in your source, we don’t charge for those syncs. However, if you re-sync all your historical data later, we do charge for that historical re-sync. This does not only apply to trials. We exclude the initial sync whenever you add a new connector to your account.
This exception includes connectors that use priority-first sync. While the sync includes historical data, none of the consumption counts towards MAR.
New tables
Initial syncs for newly-added tables do not count towards monthly active rows. That means that even after you've completed the initial sync for a connector, if you add a new table, that table benefits from the free initial sync.
Re-syncs
Re-syncs do count towards monthly active rows, including re-syncs that Fivetran initiates. Both table- and connector-level re-syncs count. Monitoring data integrity issues and performing re-syncs to fix them when needed is part of our managed service. We only perform, or ask you to perform, re-syncs when it’s absolutely necessary.
Automated schema migrations
When a new column is added to a table, every row in that table counts as an active row. It counts both if you manually choose to sync a column in a connector, and if Fivetran automatically adds a column to a connector as part of automated schema migration.
Multiples of the same connector type
Each connector in your account contributes towards your monthly active rows. It is not the connector type but the instance of the connector that matters. Even if the connectors sync the same data from the same source (with the same primary keys), they still contribute separately towards your MAR.
Same source, multiple destinations
If you have two or more of the same connector type that sync from one source to multiple destinations, each connector’s active monthly rows are counted separately. For example, if you have two Salesforce connectors, where one syncs to your staging warehouse and the other to production, each of those connectors's MAR is counted separately.
Tables without primary keys
If a table doesn’t have a primary key, we create a synthetic (hash) primary key. The composition of this primary key differs by source. For example, for Facebook Ad Insights, we use the aggregation_field, level_id, and breakdowns (that is, date, ad_id, and age) to create a synthetic primary key. MAR for these tables is based on their synthetic primary keys.
Changes to primary keys
If the primary key changes type, it doesn't affect MAR. Similarly, in a table without a primary key, if the columns from which we generate synthetic (hash) primary key change data type, it also doesn't affect MAR.
In a table without a primary key, removing or adding columns from which we generate the synthetic primary key does affect MAR. 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. Since MAR is based on unique primary keys, each of the rows in the table counts towards MAR. See also Tables without primary keys.
Transformations
Transformations do not count towards monthly active rows, because transformations happen in your destination after the data is delivered. Monthly active rows only count the rows Fivetran delivers, not events in the destination.
Fivetran system tables
The Fivetran system table FIVETRAN_AUDIT does not count towards MAR.
Other connector-specific system tables, such as FIVETRAN_QUERY, FIVETRAN_API_CALL, and FIVETRAN_FORMULA, do not count towards MAR. You can choose if you want to sync them or not.
Deletes in the source
Deletes in your source count towards your MAR if the connector supports the Capture Deletes feature. In this situation, if you delete data from your source, Fivetran soft deletes the corresponding data in your destination. Since a delete is a row update, it counts towards your MAR. To find out if your connector supports the Capture Deletes feature, go to its Fivetran documentation and check the Features table near the top of the document.
Deletes in the destination
If you delete data in your destination and Fivetran later syncs it again from your source, it counts towards your MAR.
Monitoring MAR and credit consumption
You can monitor your consumption in two ways: using the Billing and Usage tabs of your Fivetran dashboard or using the Fivetran Log connector. The Fivetran Log connector loads your MAR data into your destination, where you can run analyses on it just like you do with any other data. The Billing and Usage tabs in your Fivetran dashboard offer visual representations of your usage and are updated daily.
Using your Fivetran dashboard
If you are an account owner or have a billing role, log in to your Fivetran dashboard and go to the Billing or Usage tab.
The Billing tab displays your current and past credit consumption. Learn more in our Billing documentation.
The Usage tab displays your usage data by month. On this tab, you can:
- View paid and free MAR
- See how many credits you've used
- See daily MAR by destination, connector, or table
- View past usage data
View paid and free MAR
In the MAR section, you can see how many active rows you consumed in the selected month. This section includes two types of MAR, paid MAR and free MAR from trials (for which you are not billed). If you're viewing data for the current month, you'll see your MAR to date (month-to-date active rows).
Credits used
In the Credits Used section, you can see how many credits you used in the selected month. If you're viewing data for the current month, you'll see how many credits you've used to date (month-to-date credit usage). To learn more about how Fivetran calculates credits, click See credit calculation.
See daily MAR by destination, connector, and table
The Incremental MAR bar chart displays your paid and free MAR for each day of the selected month so that you can see trends in your consumption.
Hover over each bar to see your overall daily MAR and the daily MAR for your top five connectors.
Underneath the chart, you'll see a list of all your connectors. For each connector, we display the following information:
- The associated destination
- Paid and free MAR
- The percent of your account's MAR that the connector represents
- Percent change in MAR from the previous month
Note: We calculate the percent change by comparing this month's MAR to date to the MAR from the equivalent period last month (for example, we compare May 1-10 to April 1-10).
By default, the chart displays data for all destinations, connectors, and tables.
- To see data for a specific destination, use the drop-down menu in the top-right corner of the chart.
- To see data for a specific connector or connectors, click Select connectors. Select the connector(s) from the list underneath the chart.
- To see data for a specific table or tables, find the associated connector in the list underneath the chart and click the right arrow next to Change from last month. Select the table(s) from the list.
View past usage data
By default, the Usage tab shows data from the current month. To see past usage data, use the drop-down menu at the top of the Usage tab to select the month you'd like to view.
Using the Fivetran Log Connector
The Fivetran Log Connector includes table-level MAR across all connectors in your destination in the ACTIVE_VOLUME table. To understand what is driving the overall MAR within your account, use our sample queries to review MAR at the table level.
Phantom updates
We have observed that in some rare scenarios, the source attempts 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 since Fivetran captures these updates, they contribute to MAR.
Phantom updates occur when we try to mark the _fivetran_deleted column as TRUE for the deleted records in the source. For example, consider that you have a table TARGET in the destination, with column id as its primary key, and there is no record in the table with id = 2. Now, consider that you create a record with id = 2 in the source, and then delete it before our connector syncs the record. The source marks the record with id = 2 as deleted. In the following sync, we retrieve the record with id = 2 with the deleted status. We then try to update the _fivetran_deleted column to TRUE in the TARGET table. We can't update the record because the record with id = 2 does not exist in the destination. In the process, we capture a new unique (deleted) row and this row counts towards MAR.
Optimizing your credit consumption
Higher usage automatically gives you a better rate
Fivetran automatically optimizes certain aspects of your credit consumption. The number of credits per row declines as monthly usage increases. We apply that better rate automatically. See the Fivetran Service Consumption Table to learn about MAR and credit consumption rates.
Replication frequency doesn’t matter
Replication frequency makes no difference to your monthly active rows because MAR is based on how many unique rows are updated, not on how many updates occur. Maintain whatever replication frequency best serves your business needs.
Reducing MAR by blocking schemas or tables
You can reduce your monthly active rows by blocking schemas or tables from syncing if they don’t contain valuable information. The monthly active rows per connector chart in your billing dashboard shows you which connectors have the highest usage. The Fivetran Log Connector shows consumption by table to help guide these decisions. However, not all connectors support blocking schemas or tables.
Reducing MAR by blocking columns in tables without primary keys
This optimization is rare and not relevant to most customers. Column blocking only makes a difference for tables without a primary key. Because we create a synthetic primary key for these tables (see Tables without primary keys), you can reduce your MAR if you block a commonly-changing column which is used as part of the synthetic primary key. However, not all connectors support column blocking.
Connector-specific functional differences
We follow the same base principle across all our connectors to calculate MAR. MAR calculations for some connectors can be a little tricky to understand because the peculiarities of their sources require tailored sync strategies.
Azure Blob Storage and S3
We capture the file's last modified date, which 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.
Browser Upload
When you upload a new file in our browser-based CSV uploader, we count that new data as MAR. There is no concept of a free initial sync. However, we do not count monthly active rows twice if the same file is uploaded again. Only the newly added rows contribute to MAR.
File connectors (except S3 and Azure Blob Storage)
These file sources don't provide change-tracking data to help us determine if the file has been updated in the source. As a result, Fivetran re-syncs the entire file every time a sync is scheduled. 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.
Fivetran Log Connector
We do not calculate MAR for the Fivetran Log Connector.
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. Learn more in our HubSpot documentation. These re-syncs increase consumption for HubSpot.
Iterable
The following tables are append-only:
EVENTEVENT_EXTENSIONUSER_HISTORYUSER_UNSUBSCRIBED_CHANNEL_HISTORYUSER_UNSUBSCRIBED_MESSAGE_TYPE_HISTORYUSER_DEVICE_HISTORYLIST_USER_HISTORYCAMPAIGN_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 what we expect.
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 incrementally capture deletes. The data ranges of each table where changes are occurring count towards monthly active rows.
-
We re-import the tables that can’t be incrementally updated. The entire re-imported table counts towards monthly active rows.
-
We only sync new records for
SYSTEM_NOTESandSYSTEM_NOTES_CUSTOMtables. Only records created in the calendar month are considered as monthly active rows.
TRANSACTIONSandTRANSACTION_LINEStables are incrementally updated. We don't recommend frequently updating the historical records for theTRANSACTION_LINEStable, as this significantly increases the count of monthly active rows.
Oracle
When you add a new column to an Oracle table that Fivetran is 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 will have negligible impact on MAR consumption. XMIN does not capture deletes, so MAR could be slightly lower in comparison.