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 synced 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 sync or rows replicated as a result of resetting Replication Keys.
Viewing & Understanding Your Usage
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 0 - 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:
- The number of syncing tables,
- The Replication Methods used by the syncing tables,
- The Replication Frequency of your integrations, which defines how often Stitch should attempt to replicate data from the syncing tables, and
- The volume and structure of the data in the syncing 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.
Overages
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, however, 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 wipe away 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 tier.
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 that you cannot set Replication Methods for SaaS integrations at this time. To compensate for this, however, 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 uses 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.
Unsync Unneccesary Tables
To keep your row count down and your data warehouse tidy, you can also unsync any tables you don’t need.
Note that this is only applicable to database integrations and the SaaS integrations that support whitelisting, or the syncing of individual tables.
Pause Integrations
If all else fails, you can temporarily pause the integration to keep from going over your row limit.
| Related | Troubleshooting |
Questions? Feedback?
Did this article help? If you have questions or feedback, please reach out to us.