Consumption-Based Pricing Overview

Learn about our consumption-based pricing model, how we calculate monthly active rows and monthly model runs, and how you can track and optimize your usage.

---

Our pricing model is based on consumption. You are charged based on what you use.

Each month, we calculate your consumption based on the number of monthly active rows (MAR) across all connectors and destinations in your account. If you use Fivetran Transformations for dbt Core*, we determine that consumption based on the monthly model runs (MMR) of your dbt project.

You can use any Fivetran connectors you want and add or remove connectors over time. You can likewise add or remove destinations. You are charged according to your MAR usage, with no difference between connectors. Your usage can vary depending on the amount of data being updated in your source system, the sync strategy of your connector, or connectors you added or removed during that period.

As your monthly consumption increases, the cost per row declines automatically. The more unique data you sync in a billing period, the cheaper the incremental cost per unique monthly active row.

If you use Fivetran Transformations for dbt Core to perform data transformations in your destination, you are charged based on the number of dbt Core models you run through Fivetran. We connect to your Git provider and run your transformations according to a schedule you determine.

---

Monthly Active Rowslink

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, connector, and table. If a primary key is not available, we create a synthetic (hashed) primary key to ensure consistency.

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:

id	counter
a	1
b	2
c	3

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

We sync most connectors 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 connector 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 connector 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 causes a very high percentage of the tables to have MAR.

---

Monitor your MAR usagelink

Monitor your usage from your Fivetran dashboard or by using the Fivetran Log Connector. Learn how to optimize your usage.

Fivetran dashboardlink

The Fivetran dashboard allows you to monitor your usage both account-wide and for specific connectors.

Fivetran Log Connectorlink

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 Fivetran Log Connector includes table-level paid 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.

Optimize your consumptionlink

Understand your MAR usagelink

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

New connectorslink

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

Initial syncslink

Initial syncs do not count towards monthly active rows. When you first create a connector and sync the historical data in your source, we don’t charge you for those syncs. We exclude the initial sync whenever you add a new connector to your account. We don’t charge for historical syncs during trials or promotions.

Re-syncslink

We calculate MAR for re-syncs differently depending on your account type:

• Re-syncs for contracted spend accounts
• Re-syncs for credits-based accounts

New tableslink

Initial syncs for newly-added tables do not count towards monthly active rows. When you add a new table after completing the initial sync for a connector, the table benefits from the free initial sync.

New columnslink

When you sync a new column of a table, every row in the table counts as an active row.

Automated schema migrationslink

When we automatically add a column to a connector as part of automated schema migration, every row in that table counts as an active row.

Primary key data type changeslink

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 primary keyslink

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. For example, for the Facebook Ad Insights connector, we use the aggregation_field, level_id, and breakdowns (date, ad_id, and age) to create a synthetic primary key.

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 tableslink

The Fivetran system table FIVETRAN_AUDIT counts towards free MAR.

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

• FIVETRAN_QUERY
• FIVETRAN_API_CALL
• FIVETRAN_FORMULA
• FIVETRAN_FORMULA_HISTORY

History Mode tableslink

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 monthly active rows. Your MAR usage depends on the number of tables you have enabled history mode for and how frequently the data in your source system is changing.

Re-import tableslink

For some of our connectors, we re-import tables as part of the sync strategy. If we fetch some new records in the current month as part of a re-import, these new rows count as MAR.

Multiples of the same connector typelink

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 contribute separately to your MAR.

Same source, multiple destinationslink

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

Transformationslink

Transformations do not count towards monthly active rows because transformations occur in your destination after the data is delivered. Monthly active rows only count the rows we update, not events in the destination.

NOTE: If you use Fivetran Transformations for dbt Core, see the Monthly Model Runs section.

Deletes in the sourcelink

If a connector supports the Capture Deletes feature, deletes in your source count towards your MAR. If you delete data from your source, we soft delete the corresponding data in your destination by setting the system column _fivetran_deleted to TRUE. As the delete corresponds to a row update, it counts towards your MAR.

Deletes in the destinationlink

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

Rollback syncslink

If a connector 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.

Phantom updateslink

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 they contribute to MAR since we capture these updates. Phantom updates occur when we try to mark the _fivetran_deleted column TRUE for 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 subsequent sync, we retrieve the record with id = 2 with the deleted status. We 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.

---

Connector-specific functional differenceslink

We follow the same base principle across all our connectors to calculate MAR. However, MAR calculations for some connectors can be a little tricky to understand because the peculiarities of their sources require tailored sync strategies.

Ad reporting connectorslink

We do not exclude historical syncs when you add a new account to the following connectors:

• Adobe Analytics
• Adobe Analytics Data Feed
• AdRoll
• Apple App Store
• Apple Search Ads
• Criteo
• Facebook Ad Account
• Facebook Ad Insights
• Facebook Ads
• Facebook Pages
• Google Ad Manager
• Google Ads
• Google Ads Account
• Google Analytics
• Google Analytics MCF
• Google Display & Video 360
• Google Search Console
• LinkedIn Ad Analytics
• LinkedIn Company Pages
• Microsoft Advertising (formerly Bing Ads)
• Outbrain
• Pinterest Ads
• Snapchat Ads
• Taboola
• TikTok Ads
• Twitter Ads
• Verizon Media (formerly Yahoo Gemini)
• YouTube Analytics

File connectorslink

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 the connector’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 AWS 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 Log Connectorlink

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

HubSpotlink

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.

Iterablelink

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.

MongoDBlink

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

NetSuite Suite Analyticslink

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: TRANSACTIONS and TRANSACTION_LINES tables are incrementally updated. We don’t recommend frequently updating the historical records for the TRANSACTION_LINES table, as this significantly increases the count of monthly active rows.

Oraclelink

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.

PostgreSQLlink

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.

Priority-first synclink

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

• AdRoll
• Adobe Analytics
• Apple Search Ads
• Criteo
• Facebook Pages
• Google Display & Video 360
• Google Search Console
• Instagram Business
• LinkedIn Ad Analytics
• Microsoft Advertising
• Outbrain
• Pinterest Ads
• Snapchat Ads
• Taboola
• TikTok Ads
• Twitter Organic

See our MAR Management articles for a deep dive into connector-specific MAR management.

---

Monthly Model Runslink

Monthly model runs (MMR) are the number of data build tool (dbt) Core models run per month through Fivetran.

A transformation is a collection of data models that consists of a single output model and all of its upstream models and sources. Fivetran has integrated with dbt Core to power our transformations.

A model is a single SQL SELECT statement.

To calculate monthly model runs, we count each time a dbt Core model is run within the month.

The run count for the models in a transformation depends on how frequently you schedule the transformation.

---

Monitor your MMR usagelink

Monitor your transformations from your Fivetran dashboard.

The Billing and Usage tabs on the Account Management page display the billing and the MMR usage details for your account. These tabs offer visual representations of your transformations usage and are updated daily.

---

Fivetran planslink

Fivetran offers the following pricing plans:

• Starter - For small to midsize companies with no database sources.
• Standard Select - For one-person teams with low data volumes.
• Standard - For organizations with a database source that needs short sync frequencies for real-time monitoring.
• Enterprise - For enterprises having stringent internal security guidelines that need near real-time syncs and priority support.
• Business Critical - For global enterprises that need real-time data intelligence along with the highest level of data protection and compliance.

Learn more about our plans and their features on our Pricing page. Some features are limited to certain pricing plans (for example, the Fivetran REST API feature is limited to Standard Select, Standard, Enterprise, and Business Critical accounts).

---

Billing optionslink

Subscription-based plans: You either make an annual upfront purchase of Contracted Spend in bulk or add a credit card to your account and pay as you go.

• Capacity Purchase plan - A subscription-based plan which requires an annual upfront purchase of Contracted Spend in bulk. Contracted Spend is the total dollar amount purchased as listed in the Order Form.

• On-demand plan - A subscription-based plan for customers who pay per usage. You have to make an additional purchase to continue using the Fivetran Service after the initial purchase has been used.

Monthly plans: Monthly plans are not subscription-based. You are billed monthly in-arrears for usage during the prior monthly period. You can purchase a monthly plan from:

• The Billing tab on your Account Management page

• AWS Marketplace

• Google Cloud Marketplace

For more information about our plans, see the Fivetran Service Consumption Table.

---

Differences in pricing modelslink

On February 1, 2022, we simplified and optimized our consumption-based pricing model. We removed the concept of credits from our pricing model. We determine your consumption based on the monthly active rows and monthly model runs in your account. You still pay only for what you use.

The Contracted Spend model provides a direct and transparent approach to control your consumption. Instead of purchasing credits, you purchase Contracted Spend (Dollar amount).

Existing Fivetran customers on the credits-based model will migrate to the contracted spend model on account renewal.

Contracted Spendlink

In this pricing model, you commit to spend a certain amount of money, a contracted spend. Your contracted spend is consumed depending on your MAR and MMR usage for the month. The rate of consumption varies by your plan. See the rate of consumption for your plan in the Service Consumption Table.

Fivetran accounts signed up or re-contracted on or after February 1, 2022 are on the contracted spend model.

The two pricing models have the following key differences:

• Free connector re-syncs
• Standard Select plan
• Enterprise database connectors
• Plan limitations

Credits-basedlink

In our credits-based model, you purchase credits at a rate that depends on your plan. You consume credits at a logarithmically declining rate that is consistent across plans, depending on your MAR usage. We calculate your consumption of credits based on your monthly active rows across all connectors and destinations in your account.

Fivetran accounts signed up or re-contacted before February 1, 2022, are on the credits-based pricing model.