Much like the data part of a cell phone plan, each Stitch plan is allotted a certain number of replicated rows per month. For detailed info on pricing and what’s included in each plan, refer to the pricing page on our website.

Billing basics

Stitch counts the following as a ‘replicated row’:

  • A new row, or a never-before-replicated row replicated through Stitch,
  • An updated row, or an existing row that’s been changed,
  • A sub-row created from de-nesting nested data structures, and
  • A copy of an existing row. For example: Rows in tables that are replicated fully during each replication job or rows replicated as a result of resetting Replication Keys.

Viewing rows replicated in Stitch

On the Stitch Dashboard page, you can view the total number of replicated rows for all of your integrations for the current billing period.

To take a closer look at an individual integration’s usage for the current billing period, click on the integration to open up the Integration Details page.

The reset date - or the day your row count will reset to zero - can be found in the Plan Details section of your Billing page, accessed by clicking the User menu (your icon) > Billing.

Understanding your usage

When viewing the number of replicated rows in Stitch, you may be surprised by the totals. You may ask yourself: “How did Stitch replicate this many rows? There aren’t that many in my source or my data warehouse!”

Keep in mind that the total reported by Stitch is the number of replicated rows. The number of rows Stitch replicates is directly impacted by:

  1. The number of tables set to replicate,
  2. The Replication Methods used by the replicating tables,
  3. The Replication Frequency of your integrations, which defines how often Stitch should attempt to replicate data from the selected tables, and
  4. The volume and structure of the data in the selected tables. Some Stitch destinations - like Redshift and Postgres - will break apart nested records and count each sub-record as a row. Click here for an in-depth explanation of how Stitch de-nests nested records.

Because Stitch counts updated rows, copies of existing rows, and rows created from de-nesting towards your total usage, the total of replicated rows and the total number of rows in your data sources or data warehouse may not be equal.


If you exceed your monthly row allotment, an overage fee will be automatically added to that month’s invoice. There are two exceptions to this, as automatic overage charges don’t apply to Free and Enterprise plans:

  • Free Plans: Once the row limit is reached, integrations will be paused. Replication will resume either when you upgrade to a paid plan or when your billing cycle resets.
  • Enterprise Plans: Row limits for Enterprise plans is a custom setting. Please refer to your Stitch agreement for details.

The amount of the overage fee varies by plan. Details on overage fees can be found on Stitch’s pricing page.

Mitigating overages

If you’ve incurred overages, it may be worthwhile to temporarily upgrade your plan. When you upgrade, the change will be made immediately and you will only be billed for the difference between your current plan and the new plan, thus cancelling out the overages.

For example: You’re on the Basic plan which is $500 USD/month and includes 100 million rows. One month, your Mixpanel usage exceeds expectations and a total of 240 million rows are replicated. At $10 for each million rows above the limit, this would result in a total of $1,900 USD ($500 for the plan, $1,400 in overages) for the month.

Temporarily upgrading to the Premier plan - which is $1,000 USD/month and includes 250 million rows - would cancel the $1,400 USD in overages, thus saving $900.

We generally recommend switching plans mid-cycle only if the overages exceed the cost of the next-highest plan.

Reducing your usage

Switching to a higher plan may help you avoid overages in the short-term, but to avoid awkward conversations with your Accounts Payable co-workers, you’ll need a long-term strategy to reduce your usage. Below are some simple tips we recommend for keeping your row count low.

Reduce the Replication Frequency

The default Replication Frequency for the majority of integrations is 30 minutes. If you can manage going without the freshest data, you can dial back the interval to something less frequent - for example, every hour or every 6 hours.

Keep in mind that the Replication Frequency setting applies to the entire integration, not individual tables. This is especially important if there are a lot of tables that use Full Table Replication in the integration.

Check table Replication Methods

If a database integration is eating up a lot of your row limit, check the Replication Methods of the tables you’ve set to sync. Whenever possible, we recommend using Incremental Replication, as this can significantly reduce the amount of redundant data replicated by Stitch.

Note: With the exception of Salesforce, you cannot set Replication Methods for SaaS integrations at this time. To compensate for this, you can set the integration to replicate less often.

Get to know your SaaS integrations

While we try to use Incremental Replication for SaaS integrations whenever possible, replicating high numbers of rows is sometimes unavoidable. This can be because:

  • The integration generates massive amounts of data. Mixpanel, for example, typically contains large amounts of data.
  • Some tables require Full Table Replication or querying for a time range (attribution window) to ensure accuracy.
  • The integration contains nested data structures. If you’re using a data warehouse that doesn’t natively support nested structures, Stitch will de-nest these structures and create sub-rows which will result in a higher number of replicated rows.

    For an in-depth walkthrough of how JSON arrays are deconstructed in Stitch, as well as what arrays are in the first place, check out the Handling of Nested Data Structures & Row Count Impact guide.

To find out more about your SaaS integrations’ data structure and replication methods, we recommend checking out our extensive SaaS integration docs. Every SaaS integration has detailed info about the tables Stitch will replicate and the methods used to do so.

De-select unnecessary tables

To keep your row count down and your data warehouse tidy, you can also de-select any tables you don’t need.

Note: This is only applicable to database integrations and the SaaS integrations that support whitelisting, or the replication of individual tables.

Pause integrations

If all else fails, you can temporarily pause the integration to keep from going over your row limit.

Note: Pausing an integration will only prevent the extraction of additional records. Loading will continue for records that have been extracted prior to the pause.

For example: If there are records currently in Preparing when an integration is paused, Stitch will continue to load these records, complete the current replication job, and count them towards your usage.

Questions? Feedback?

Did this article help? If you have questions or feedback, feel free to submit a pull request with your suggestions, open an issue on GitHub, or reach out to us.