Usage-Based Pricing
Fivetran’s pricing model involves three basic principles:
Pricing is usage-based. You are charged based on what you use each month.
You only pay for 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, connector, and table. Once a row is active, it is only counted once per month - no matter how many updates are made that month.
You can choose which pricing plan fits your requirements. Fivetran offers the following pricing plans:
- Free - Get all the features of our Standard plan up to 500,000 MAR per month. We recommend this plan if you have very low data volumes or if you want to trial Fivetran on low volumes of data.
- Starter - Access our entire library of SaaS, events, and files connectors. This plan is best for small teams not yet ready to connect a database source.
- Standard - Unlock data from your database sources. Our most popular plan, Standard is ideal for teams that need robust cross-departmental analytics.
- Enterprise - Access high-volume agent connectors, fastest sync times, and advanced user permissioning. Enterprise is ideal for data teams that need real-time data delivery and have strict governance requirements.
- Business Critical - Ensure the highest levels of data protection and compliance on Business Critical. This plan is most popular among large Enterprise businesses or anyone in the healthcare, insurance, and finance industries.
- Private Deployment - Deploy Fivetran's HVR as a standalone solution if you require highly secure connections. This usage-based subscription plan requires you to send the consumption data files (MAR) to Fivetran at least once a quarter.
You can compare features across our five plans on our Pricing Features page. Also, to see examples of pricing in action, check out our Pricing Guide.
Plan limitations
Some features are limited to specific pricing plans. Learn more about our plans and their features on our Pricing page.
The most important plan limitations include:
- The Free plan has a maximum monthly MAR consumption of up to 0.5 million.
- The Starter plan has a maximum user capacity of 10 users.
- Only the Enterprise and Business Critical plans offer access to enterprise database connectors and Hybrid Deployment.
Enterprise database connectors
You can sync data from the following database sources only if you are on the Enterprise or Business Critical plans:
You can sync data using the following High-Volume Agent connectors if you are on the Enterprise or Business Critical plans:
Hybrid Deployment
With the Hybrid Deployment model, you can process data within your own network while Fivetran acts as a unified control plane for all your data movements. This model is designed for organizations who must keep their data local for security or compliance reasons but still want to benefit from Fivetran's managed service.
We support Hybrid Deployment for multiple connectors and destinations. Learn more in our Hybrid Deployment documentation.
Plan renewal
If you are on our Standard plan and are using the enterprise database connectors, you must upgrade to the Enterprise plan during account renewal.
If you are on our Starter plan and have more than 10 users in your account, you must upgrade to the Standard plan or remove users during account renewal.
IMPORTANT: We apply these billing rules to the following plan-renewal scenarios:
We bill you the discounted rate for the whole month when you renew your plan at a discounted rate during the month.
We bill you spend balance from the previous contract if you renew your plan without a rollover during the month.
Plan conversions
You can change your pricing plan in the Billing & Usage section in your Fivetran dashboard. We will detail the changes that you will gain or lose with a Confirm upgrade or Confirm downgrade prompt.
NOTE: Plan conversions are not available for Sales-assisted accounts and accounts that pay through a marketplace.
NOTE: We bill you the cheapest plan rate for the whole month when you switch pricing plans.
Plan upgrades
Plan upgrades may only require payment submission. You will have to enter your payment information if upgrading from the Free plan.
Plan downgrades
Plan downgrades require acknowledging and consenting to losing features. We will outline the features that you will be losing when downgrading an account.
If you are currently using features that only exist on your pricing plan, such as more than ten users on an account, you will have to manually undo that feature before downgrading.
You will need to confirm your consent to losing certain features.
Billing options
You can sign up for Fivetran on an annual subscription or a monthly pay-as-you-go model.
The 14-day free trials for all new accounts can help you determine whether Fivetran meets your requirements before making any commitments.
Annual contracted spend model
The contracted spend model is a subscription-based plan that requires an annual upfront purchase of contracted spend in bulk. Contracted spend is the total amount purchased as listed in the Order Form. Your contracted spend is consumed depending on your MAR 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.
With this plan, the Starter, Standard, Enterprise, and Business Critical plans are available by default.
Monthly pay-as-you-go (PAYG)
The monthly PAYG plan is not subscription-based. You are billed monthly in arrears for usage during the prior monthly period. This plan offers flexibility as you can cancel anytime, and there is no MAR consumption minimum. With this plan, the Free, Starter, Standard, and Enterprise plans are available by default.
You can purchase a monthly PAYG plan from:
Differences between annual contracted spend and PAYG
Both billing options have distinct advantages as we strive to suit the needs of a diverse range of customer requirements. The table below lists the most crucial differences between the annual and PAYG billing models:
Point of comparison | Annual contracted spend | Pay-as-you-go |
---|---|---|
Payment frequency | Annual, bi-annual, or quarterly | Month to month |
Commit term | Annual | Monthly |
Default plans | Starter, Standard, Enterprise, and Business Critical | Free, Starter, Standard, and Enterprise |
Minimums | $12,000 | No minimums |
Free plan | No | Yes |
Discounts | 5% built-in discount | List price |
Free re-syncs | Yes | Yes |
Enterprise database connectors | Yes, with an Enterprise or Business Critical plan | Yes, with an Enterprise plan |
Billing conversions
We apply these billing rules if you switch from a monthly pay-as-you-go plan to annual contracted spend, and vice versa:
- We bill you the annual rate for the whole month when you switch from the monthly pay-as-you-go plan to the annual contracted spend model.
- We bill you the pay-as-you-go rate for the whole month when you switch from the annual contracted spend model to the monthly pay-as-you-go plan.
- We bill you the pay-as-you-go rate for the whole month and pull usage from your remaining balance if you have a remaining balance when you switch from the annual contracted spend model to the monthly pay-as-you-go plan. We also expire any balance that would have been left over after the annual contract expired.
Tracking Spend
To view your monthly spend, you can access your Billing and Usage data in your Fivetran dashboard.
Billing - You can access billing in the Billing and Usage section under your Account Settings. The Billing tab displays your current and past monthly spend details. You can also view and change your plan and payment details.
Usage - You can access usage in the Billing and Usage section under your Account Settings. The Usage tab displays the usage information for your account by month.
Free trials include a usage and pricing estimate. Every customer and every data source is different. The most accurate way to get a usage and pricing estimate is by starting a free trial or a connector free use period.
All account free trials include a trial estimate seven days after the initial sync completes. Once you’re a customer, any new connector includes 14 days of free usage and a usage estimate seven days after your initial sync completes.
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, connector, and table. If a primary key is not available, we create a synthetic (hashed) primary key to ensure consistency. Fivetran uses a special data structure called HyperLogLog (HLL) to track MAR. HLL uses a hash value from the primary keys to count unique MAR.
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 usage
Monitor your usage from your Fivetran dashboard or by using the Fivetran Platform Connector. Learn how to optimize your usage.
Fivetran dashboard
The Fivetran dashboard allows you to monitor your usage both account-wide and for specific connectors.
Account-wide MAR usage
In Fivetran, go to Account Settings > Billing & Usage to see the billing and MAR usage details for your account. These tabs offer visual representations of your usage and are updated daily.
The Billing tab displays your current and past spend details. For more information about the Billing tab, see Account Settings: Billing & Usage.
The Usage tab displays the usage information for your account by month. For more information about the Usage tab, see Account Settings: Billing & Usage.
Connector-specific MAR usage
The Usage tab on the Connector Details page displays the MAR usage for a given connector and its tables. For more information about the Usage tab, see Connectors: Usage.
Fivetran Platform Connector
The Fivetran Platform Connector loads your MAR data into your destination, where you can run analyses on it just like you do with any other data. To understand what is driving the overall MAR within your account, use our sample queries to review MAR at the table level.
HVR
Fivetran's pricing for HVR varies based on the pricing plan and licensing model. Users must subscribe to the Business Critical or Private Deployment pricing plans. Moreover, users must use consumption-based or usage-based pricing depending on their pricing plan. Read our documentation on pricing plans for HVR and licensing for HVR to learn more.
Historical MAR
Historical MAR represents data that already exists in the source or was synced when the table or connector was created.
Examples of historical MAR include:
- Initial table syncs
- Table schema changes that lead to a full table re-sync (e.g., 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
Incremental MAR
Incremental MAR represents new or updated data in the source since the last sync.
Examples of incremental MAR include:
- Overlapping incremental syncs
- Reimported table syncs that occur when no cursor column is provided
- Reporting connector rollback syncs that occur during a conversion window
Optimize your consumption
Higher usage leads to a better rate
We automatically optimize certain aspects of your MAR consumption. Your cost per row declines automatically as your monthly consumption increases. To learn more about MAR rates, see the Fivetran Service Consumption Table.
Sync frequency
The connector’s sync 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 sync frequency best serves your business needs.
Block 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 Platform Connector shows consumption by table to help guide these decisions. However, not all connectors support blocking schemas or tables.
Block columns in tables without a primary key
You can reduce your monthly active rows by blocking columns for tables without a primary key. Column blocking can make a difference because we create a synthetic primary key for these tables, you can reduce your MAR if you block a commonly-changing column that is used as part of the synthetic primary key. However, not all connectors support column blocking.
IMPORTANT: You can't block primary key columns.
MAR Increases
Sharp increases in MAR can occur for the following reasons:
- It is the beginning of the month
- A free trial ended
- Changes in the source
- User error
- Connector paused and then resumed
Beginning of the month
At the beginning of each month, you may see a sudden increase in MAR due to frequent changes in a large number of rows. Once a row is active, it is only counted once. Any additional changes to counted rows won't count towards MAR. Any remaining data use will mostly come from new records.
We reset the count of your active rows at the end of the month. All rows go back to being inactive, and your active rows count goes back to zero. During the first sync on the first day of the month, Fivetran fetches new rows and existing rows with updated values from the source, and these rows become active. Since we only count these rows once per month, you may observe what seems like an increase in your MAR usage on the first day of each month. You may also observe what seems like an increase in MAR when most rows have frequent value changes.
You will not observe what seems like an increase in your MAR usage if the first sync doesn’t occur on the first of the month.
After the free trial
Fivetran offers a free trial period for new accounts and a free use period for new connectors. Once you purchase Fivetran after your free trial, your MAR counter resets. Any new, changed, or deleted rows you sync as distinct primary keys count towards your paid MAR for the month. If the rows you synced during the free period don't change, we don't count the rows as active rows. We only count the rows that you add, change, or delete.
For example, see how MAR is calculated during and after a free trial:
Day 1: You are trialing Fivetran. One of the connectors syncs two primary keys, pk_1 and pk_2, to the destination. We count both the rows as free MAR.
Day 2: You upgrade your trial account to a paid one. The connector syncs another primary key, pk_3. We count this row as paid MAR.
Day 3: You update one of the primary keys, pk_1. We now count this row as paid MAR. As you didn't update pk_2, we still count the row as free MAR.
Once the free account trial period ends, most of your active rows count towards MAR, since it is the first active instance of the primary keys. You will see a one-time increase in your MAR on the first day of the paid usage because we count all the distinct primary keys you sync.
Following the conclusion of the new connector's free use period, you will see a corresponding increase in the paid MAR for the connector.
Changes at the source
Administrators, users, and integration teams should collaborate to understand how the data source interacts with Fivetran.
- Integration teams must know about connector types.
- Administrators must understand how to provide source access.
- Users must outline their expectations from the solution. Often, increases in MAR are due to changes in the source. Adding a new column or table leads to MAR increases. It's important to communicate with your stakeholders on how their sources impact usage and ensure every table you're moving provides value to the team.
User-related errors
Unexpected data use can occur when you unpause a connector or delete a connector, then recreate it with exactly the same name. Both cases lead to an increase in MAR. To avoid unexpected data use, we recommend re-syncing paused connectors. Also, every time you create a new connector, ensure you use a unique name. You can do these either through the Connectors page or the REST API.
Connector paused and then resumed
MAR usage may suddenly increase if a connector was paused for a period of time and then resumed. The first sync after resuming a connector extracts and loads all the data that was updated in the source during the time the connector was paused.
Understand your MAR usage
Learn how operations in your Fivetran account impact your MAR usage.
New connectors
Every new connector you create has 14 days of use at no cost.
Release phases
Every Private Preview connector is free. We charge for connectors when they are in Beta or Generally Available. Connector pricing varies on functionality. See our core concepts documentation for more information.
Initial syncs
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-syncs
All plans offer 14 days of use at no cost for new connectors.
In the following scenarios, re-syncs count towards free MAR:
- Manual re-syncs related to initial connector setup, debugging, and troubleshooting purposes are free. This includes table-level and connector-level re-syncs and historical re-syncs initiated from the Fivetran dashboard or using our REST API. You may trigger unlimited re-syncs for these purposes each month. However, customers cannot trigger re-syncs to skirt their obligations under their signed Agreement with Fivetran.
- Re-syncs that Fivetran triggers in your dashboard or while fixing incidents count towards free MAR. We only perform a re-sync when it is absolutely necessary.
- Automatic table re-syncs triggered by database connectors as part of their sync strategies or due to schema changes are free.
Re-sync limitations
There are two exceptions when re-syncs count towards paid MAR:
- Schema changes in non-database connectors that trigger automatic table re-syncs count towards paid MAR.
- Automatic re-syncs of a database table you had previously excluded from your syncs count towards paid MAR.
Re-syncs allow customers to troubleshoot their connectors without worrying about the impact of those efforts on their total MAR for the month. However, Fivetran prohibits customer attempts to use customer-triggered re-syncs to disguise paid usage as free usage of Fivetran products and services.
Upon discovering conduct that Fivetran deems, in its sole reasonable discretion, a violation of this limit (i.e., programmatic re-syncs as a data movement strategy), Fivetran may charge customers for such non-conforming use and take any other measures set forth in the Agreement between the parties.
New tables
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 columns
When you sync a new column of an existing table, every row in the table that is backfilled with data will count as an active row. Rows that do not have backfilled data and have a null value for the new column will not be considered active.
Automated schema migrations
When we automatically add a column to a connector as part of automated schema migration, every row in the table that is backfilled with data will count as an active row. Rows that do not have backfilled data and have a null value for the new column will not be considered active.
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 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 tables
We re-import tables in full during every sync as part of the sync strategy for some of our connectors. During a re-import sync, we activate all rows in the table that aren't already active. This differs from our incremental tables that only activate changed rows. However, each unique primary key in the table is still charged once per month.
For example, let's say that you have a re-import table with one-hundred rows from the previous month with zero changes, the first re-import at the start of the new month will result in one-hundred MAR. Then, there is another sync 24 hours later and there are twenty new rows. During this second sync, Fivetran will re-import the full one-hundred-twenty rows but the MAR charge will just be twenty.
Since the first sync of re-import tables captures all rows regardless of changes, the MAR increase at the beginning of each month is often more pronounced for connectors with re-import tables.
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 contribute separately to your MAR.
Same source, multiple destinations
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 destination 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.
Transformations
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.
Data blocking
You can block specific columns and tables from replicating to your destination. However, you can't block primary key columns. If you update a blocked column that is not a primary key column in your source table, the update counts towards your MAR.
Deletes in the source
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 destination
If you delete data in your destination and later sync it again from your source, it counts towards your MAR.
Rollback syncs
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 updates
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 differences
We calculate MAR in the same way for all our connectors. However, MAR calculations for some connectors can vary due to significant differences in:
- API capabilities
- Connector configuration
- Source configuration
- Access management
- Underlying data models
- Raw data formats
Therefore, some connectors 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 the connector's configured location:
- Initial sync (May 1st) – file has 10 rows
- Next sync (May 15th) – file has 15 rows
- 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.
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.
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
andSYSTEM_NOTES_CUSTOM
tables. We consider only the records created in the calendar month as monthly active rows.
NOTE: We update the
TRANSACTIONS
andTRANSACTION_LINES
tables incrementally. We don't recommend frequent updates of the historical records for theTRANSACTION_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.
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 the connector's free trial period as soon as a priority-first sync is initiated.
Connector | Priority Fetch Period | Tables synced on a priority-first basis | Backward Sync Duration |
---|---|---|---|
Acculynx | 30 days | JOB and its child tables | 6 hours |
Adjust | 30 days | All tables | 6 hours |
Adobe Analytics | 15 days | All reporting tables | 6 hours |
AdRoll | 30 days | All reporting tables | 6 hours |
Afterpay | 90 days | PAYMENT table and its child tables | 6 hours |
Amazon Ads | 30 days | All reporting tables | 6 hours |
Amazon Selling Partner | 7 days | FINANCE and ORDERS modules | 6 hours |
Amplitude | 15 days | All tables | 6 hours |
Apple Search Ads | 30 days | All reporting tables | 6 hours |
Assembled | 15 days | AGENT_STATE , DAILY_REPORT_METRIC , EVENT_CHANGE , FORECAST , FORECAST_TOTAL , HOURLY_REPORT_METRIC , and REQUIREMENT tables | 6 hours |
BigCommerce | 2 days | CHANNEL , CUSTOMER , ORDERS , PRODUCT , PRICE_LIST , and SUBSCRIBER tables | 6 hours |
Braintree | 2 days | CREDIT_CARD_VERIFICATION table | 6 hours |
Checkout.com | 7 days | BALANCE_REPORT , CUSTOMER , DISPUTE , FINANCIAL_ACTION_REPORT , INSTRUMENT , PAYMENT , PAYMENT_ACTION , PAYOUT_REPORT , and REPORT tables and their child tables | 6 hours |
ChurnZero | 15 days | CHURN_SCORE_CALCULATION and CHURN_SCORE_FACTOR_CALCULATION tables | 6 hours |
Clazar | 15 days | BUYER , CONTRACT , LISTING ,OPPORTUNITY , and PRIVATE_OFFER tables | 6 hours |
Clearpay | 90 days | PAYMENT table and its child tables | 6 hours |
Clockodo | 15 days | WORKTIME table | 6 hours |
Commercetools | 30 days | CART , CUSTOMER , INVENTORY , ORDERS , PAYMENT , and PRODUCT tables and their child tables. | 6 hours |
Constant Contact | 7 days | CONTACT and EMAIL_CAMPAIGN tables and their child tables. | 6 hours |
Criteo | 30 days | All reporting tables | 6 hours |
Datadog | 1 day | AUDIT , CI_VISIBILITY_PIPELINE , CI_VISIBILITY_TEST , EVENT , LOG , RUM_EVENT , and SPAN tables | 6 hours |
Deposco | 30 day | BILLABLE_TRANSACTION , BILLING_INVOICE , PURCHASE_ORDER , SALES_ORDER , and SHIPMENT tables | 6 hours |
Dialpad | 15 days | CALL table | 6 hours |
Donus | 1 day | GRANTS , GRANTS_REPORT , MEMBER , and PAYMENT tables and their child tables | 5 hours |
Duoplane | 7 days | PURCHASE_ORDER , PRODUCT , and SHIPMENT tables | 6 hours |
Eloqua | 7 days | CONTACT_ACTIVITY and custom object tables | 6 hours |
Facebook Pages | 30 days | All page insights tables | 6 hours |
Fourkites | 7 days | SHIPMENT table and its child tables | 6 hours |
Front | 30 days | CONTACT and CONVERSATION tables and their child tables | 6 hours |
Gainsight Product Experience | 7 days | CUSTOM_EVENT , EMAIL_EVENT , ENGAGEMENT_VIEW_EVENT , EVENT_IDENTIFICATION , FEATURE_MATCH_EVENT , FORM_SUBMIT_EVENT , LEAD_EVENT , PAGEVIEW_EVENT , SEGMENT_MATCH_EVENT , SESSION_EVENT , SURVEY_RESPONSE , and USERS tables | 6 hours |
Google Analytics 360 | 15 days | All tables | 6 hours |
Google Analytics 4 | 30 days | Reporting tables | 6 hours |
Google Analytics 4 Export | 1 day | All tables | 6 hours |
Google Display & Video 360 | 30 days | All tables | 6 hours |
Google Search Ads 360 | 15 days | All tables | 6 hours |
Google Search Console | 7 days | Reporting tables | 6 hours |
Healthie | 30 days | APPOINTMENT and FORM_ANSWER_GROUP tables | 6 hours |
Help Scout | 15 days | CUSTOMER_HISTORY and CONVERSATION_HISTORY tables and their child tables | 6 hours |
Hilti On!Track | 60 days | TRANSFER table | 6 hours |
HubSpot | 1 day | CUSTOM_EVENT , EMAIL_EVENT_BOUNCE , EMAIL_EVENT_CLICK , EMAIL_EVENT_DEFERRED , EMAIL_EVENT_DELIVERED , EMAIL_EVENT_DROPPED , EMAIL_EVENT_FORWARD , EMAIL_EVENT_OPEN , EMAIL_EVENT_PRINT , EMAIL_EVENT_SENT , EMAIL_EVENT_SPAM_REPORT , EMAIL_EVENT_STATUS_CHANGE , EMAIL_EVENT_SUPPRESSED , EVENT , FEEDBACK_SUBMISSION , FEEDBACK_SUBMISSION_CONTACT , FEEDBACK_SUBMISSION_PROPERTY_HISTORY , FEEDBACK_SUBMISSION_TICKET , LEAD , LEAD_COMPANY , LEAD_CONTACT and LEAD_PROPERTY_HISTORY tables | 6 hours |
Instagram Business | 29 days | USER_INSIGHTS table | 6 hours |
Iterable | 7 days | EVENT table | 6 hours |
Jibble | 15 days | ACTIVITY ,GROUPS ,SCHEDULE ,TIME_ENTRY , and TIMESHEET tables | 6 hours |
JobNimbus | 30 days | All tables | 6 hours |
Klaviyo | 7 days | EVENT tables | 6 hours |
Liftoff | 30 days | REPORT tables | 6 hours |
LinkedIn Ad Analytics | 30 days | All reporting tables | 6 hours |
Mailjet | 15 days | CONTACT_LIST_SIGNUP , MESSAGE , MESSAGE_INFORMATION ,GEO_STATISTICS ,TOPLINK_CLICKED and CLICK_STAT tables | 6 hours |
Marketo | 0 days | All activity (and dependent) tables and LEAD table | 6 hours |
Maxio Chargify | 7 days | EVENT , INVOICE , PRODUCTS_PRICE_POINT , PRODUCT , SUBSCRIPTION , and SUBSCRIPTION_COMPONENT tables | 6 hours |
Microsoft Advertising | 30 days | All reporting tables | 6 hours |
Mixpanel | 15 days | EVENT table | 6 hours |
Nice | 30 days | AGENT_PERFORMANCE , CONTACT , DISPOSITION , INTERACTION_HISTORY , SKILL_CALL_DATA , SKILL_SUMMARY , SLA_SUMMARY , STATE_HISTORY , WFM_DATA_ADHERENCE , WFM_DATA_CONTACT , WFM_DATA_PERFORMANCE , and WFM_DATA_SCORECARD tables. | 6 hours |
Ometria | 7 days | PROFILE , ORDERS , and UNSUBSCRIBED_CONTACT tables | 6 hours |
On24 | 30 days | ATTENDEE , EVENT , LEAD , PRESENTER , and REGISTRANT tables | 6 hours |
Optimizely | 30 days | DECISION and CONVERSION tables and their child tables | 6 hours |
Ordway | 7 days | INVOICE , JOURNAL , PAYMENTS , REVENUE_SCHEDULE , and USAGE tables and their child tables | 6 hours |
Outbrain | 30 days | All reporting tables | 6 hours |
PagerDuty | 15 days | LOG_ENTRIES tables | 5 hours |
Packiyo | 15 days | ORDERS table | 6 hours |
Pardot | 14 days | EMAIL , VISIT , and VISITOR_ACTIVITY tables | 6 hours |
Pendo | 7 days | ACCOUNT_HISTORY , VISITOR_HISTORY , FEATURE_EVENT , PAGE_EVENT , GUIDE_EVENT , TRACK_TYPE_EVENT , POLL_EVENT , and EVENT tables | 6 hours |
Pinterest Ads | 30 days | All reporting tables | 6 hours |
Quorum | 7 days | BILL table | 6 hours |
Recharge | 15 days | ADDRESS , ADDRESS_DISCOUNT , ADDRESS_SHIPPING_LINE , CHARGE , CHARGE_DISCOUNT , CHARGE_LINE_ITEM , CHARGE_ORDER_ATTRIBUTE , CHARGE_SHIPPING_LINE , CHARGE_TAX_LINE , CHECKOUT , CHECKOUT_LINE_ITEM , CUSTOMER , DISCOUNT , METAFIELD , ONE_TIME_PRODUCT , ORDER , ORDER_LINE_ITEM , PAYMENT_METHOD , PLAN , SUBSCRIPTION , SUBSCRIPTION_HISTORY , and UTM_TAG tables | 6 hours |
Reddit Ads | 30 days | All reporting tables | 6 hours |
Reltio | 7 days | ENTITY , INTERACTION , MATCH , and RELATION tables | 6 hours |
Ricochet360 | 30 days | LEAD table and its child tables | 6 hours |
Rithum | 15 days | ORDERS and PRODUCT tables | 6 hours |
Salesforce Commerce Cloud | 15 days | CAMPAIGN , COUPON_REDEMPTION , CUSTOMER , ORDER , and PRODUCT tables | 6 hours |
Salesforce Marketing Cloud | 1 day | CHAT_INBOUND_MESSAGE_LOG , CHAT_POTENTIAL_UNSUBS , CHAT_TRACKING , EMAIL , EVENT , LIST , LIST_SUBSCRIBER , MOBILE_PUSH_DETAIL_EXTRACT , PUSH_MESSAGE , SEND , SMS_MESSAGE_TRACKING , SUBSCRIBER , and TRIGGERED_SEND tables | 6 hours |
Shopify | 15 days | ABANDONED_CHECKOUT , COLLECTION , CUSTOMER , DRAFT_ORDER , ORDER , PRICE_RULE , PRODUCT , and TENDER_TRANSACTION tables | 6 hours |
Snapchat Ads | 30 days | All reporting tables | 6 hours |
StarRez | 15 days | All tables except BOOKING_TYPE , CUSTOM_FIELD_USAGE_TYPE_ENUM , ENROLLMENT_TYPE_ENUM , ENTRY_STATUS_ENUM , FIELD_DATA_TYPE_ENUM , GENDER_ENUM , GL_POSTING_TYPE_ENUM , GROUP_STATUS_ENUM , GROUP_STATUS_ENUM , NATIONALITY , ROOM_RATE_DURATION_ENUM , ROOM_SPACE_TYPE_ENUM , ROOMSPACE_CLOSED_REASON , and TRANSACTION_TYPE_ENUM tables | 6 hours |
sticky.io | 15 days | CONTACT and ORDERS tables | 6 hours |
Stripe | 30 days | All tables and their child tables except APPLE_PAY_DOMAIN , CHECKOUT_SESSION , CREDIT_NOTE , EARLY_FRAUD_WARNING , PLAN , and SKU tables | 6 hours |
Taboola | 30 days | All reporting tables | 6 hours |
The Movie Database | 12 days | MOVIE, TV_SERIES tables and their child tables | 6 hours |
The Trade Desk | 30 days | All reporting tables | 6 hours |
TikTok Ads | 30 days | All reporting tables | 6 hours |
Twitter Organic | 30 days | ORGANIC_TWEET_REPORT table | 6 hours |
UKG Pro | 30 days | COMPENSATION , DIRECT_DEPOSIT , EMPLOYEE_CHANGE , EMPLOYEE_CONTRACT , EMPLOYEE_GLOBAL_BANK , EMPLOYEE_GLOBAL_LOCALIZATION_ELEMENT , EMPLOYEE_JOB_HISTORY , EMPLOYEE_PAY_DEDUCTION_ELEMENT , EMPLOYEE , and EMPLOYMENT tables | 6 hours |
Xactly | 30 days | All tables except COMMISSION_SUMMARY and QUOTA_SUMMARY tables. | 6 hours |
Yahoo DSP | 30 days | All reporting tables | 6 hours |
Zonka Feedback | 15 days | RESPONSE table and its child tables | 6 hours |
Zendesk | 15 days | TICKET table and its child tables | 6 hours |
See our MAR Management articles for a deep dive into connector-specific MAR management.
* dbt Core is a trademark of dbt Labs, Inc. All rights therein are reserved to dbt Labs, Inc. Fivetran Transformations is not a product or service of or endorsed by dbt Labs, Inc.