If you’ve worked with Fivetran for a while, you’ve probably seen this pattern: the bill looks manageable for a few months, then suddenly jumps by 50% or more. In some cases, teams see their costs double or triple without any major new projects.
The reason lies in Fivetran’s Monthly Active Rows (MAR) model. It charges by the rows synced, but the details (broken down by connector, schema, or table) aren’t visible on the invoice. This leaves teams with very little ability to:
- Understand which connectors are driving spend
- Anticipate month-end costs before the bill arrives
- Catch unexpected usage spikes in time to act
For data teams, this unpredictability makes budgeting difficult and creates unnecessary friction with finance.
Table of Contents
A Snowflake-Native Way to Regain Control
To address this, we built ETL Cost Monitor: a Snowflake-native application designed specifically for monitoring Fivetran usage and costs, with plans to add other ETL tools soon as well.
The app runs entirely within your Snowflake environment and provides:
- Granular cost visibility: Breakdowns by connector, schema, and table
- Forecasting: Current and projected monthly costs based on usage to date
- Alerting: Notifications when costs exceed thresholds or unusual activity occurs
- Actionable insights: Identification of high-growth sources before they drive up the bill
👉 Learn more about ETL Cost Monitor
Why It Matters
The real challenge isn’t the cost of Fivetran itself, but the lack of transparency. Without clear visibility into usage, teams are forced into reactive end-of-month reconciliations between engineering and finance.
ETL Cost Monitor changes that dynamic:
- Data engineers can explain why costs changed, backed by table- and connector-level data.
- Finance teams get predictable spend tracking instead of unexpected overruns.
- Leaders can plan ahead with confidence, knowing usage trends won’t catch them off guard.
This isn’t about cutting corners. It’s about making sure your ETL spend is transparent, explainable, and under control.
How It Works
- Install the app in Snowflake and grant it access to Fivetran usage tables (fivetran_metadata.incremental_mar).
- Use prebuilt dashboards and SQL templates to analyze costs, trends, and high-usage sources.
- Set up optional alerts through Snowflake tasks and email integrations to stay ahead of anomalies.
Because it all runs in Snowflake, no data leaves your environment.
Example in Practice
A few months ago, our data team noticed that Fivetran costs had spiked nearly 40% in a single billing cycle, without any new connectors being added. At first glance, spend appeared to jump “out of nowhere,” but using ETL Cost Monitor, we traced it back systematically.
- Connector Diagnosis
- Running a connector-level breakdown immediately flagged a Salesforce connection that had almost doubled in incremental row volume compared to the previous month.
- Interestingly, this wasn’t captured in Fivetran’s billing portal — the invoice just showed a lump-sum increase.
- Table-Level Root Cause Analysis
- Digging into the table-level usage, we saw that a previously stable opportunity_history table was now ingesting millions of additional rows per day.
- Further investigation revealed that a schema evolution (caused by Salesforce enabling historical tracking on several fields) had triggered Fivetran to reprocess large historical datasets.
- Forecasting the Impact
- By running our in-app forecasting query, we estimated that if left unchecked, this single connector would add ~$18K in unbudgeted costs at month-end — equivalent to an annualized overrun of more than $200K.
- The fact that we could quantify this risk mid-cycle was key.
- Corrective Action
- We adjusted the sync configuration to exclude high-churn historical fields that weren’t analytically relevant.
- We also added an alert at the connector level to ensure we’d be notified immediately if similar row-growth anomalies occurred again.
In total, the issue was detected, explained, and corrected before it could hit our invoice. Instead of escalating into a finance fire drill, it became a one-hour investigation with a data-driven resolution.
Here’s How to Generate Your Report (Step-by-Step)
To replicate the investigation above, the team relied on SQL templates bundled with ETL Cost Monitor:
Step 1: Identify the Top Tables Driving Paid Row Volume This Month
sql
SELECT
connection_name,
schema_name,
table_name,
SUM(incremental_rows) AS total_rows
FROM fivetran_metadata.incremental_mar
WHERE DATE_TRUNC('month', measured_date) = DATE_TRUNC('month', CURRENT_DATE())
AND free_type = 'PAID'
GROUP BY connection_name, schema_name, table_name
ORDER BY total_rows DESC
LIMIT 10;Step 2: Compare Current vs. Last Month’s Volume (Growth Detection)
sql
WITH current_month AS (
SELECT
connection_name,
SUM(incremental_rows) AS current_rows
FROM fivetran_metadata.incremental_mar
WHERE DATE_TRUNC('month', measured_date) = DATE_TRUNC('month', CURRENT_DATE())
AND free_type = 'PAID'
GROUP BY connection_name
),
last_month AS (
SELECT
connection_name,
SUM(incremental_rows) AS last_rows
FROM fivetran_metadata.incremental_mar
WHERE DATE_TRUNC('month', measured_date) = DATE_TRUNC('month', CURRENT_DATE() - INTERVAL '1 month')
AND free_type = 'PAID'
GROUP BY connection_name
)
SELECT
c.connection_name,
c.current_rows,
COALESCE(l.last_rows, 0) AS last_rows,
(c.current_rows - COALESCE(l.last_rows, 0)) AS growth_rows,
ROUND(((c.current_rows - COALESCE(l.last_rows, 0)) / NULLIF(l.last_rows,0)) * 100, 2) AS pct_growth
FROM current_month c
LEFT JOIN last_month l ON c.connection_name = l.connection_name
ORDER BY pct_growth DESC
LIMIT 5;Step 3: Forecast End-of-Month Costs (Proactive Prevention)
sql
WITH daily_usage AS (
SELECT
DATE(measured_date) AS usage_day,
SUM(incremental_rows) AS rows_ingested
FROM fivetran_metadata.incremental_mar
WHERE DATE_TRUNC('month', measured_date) = DATE_TRUNC('month', CURRENT_DATE())
AND free_type = 'PAID'
GROUP BY usage_day
),
average_daily AS (
SELECT AVG(rows_ingested) AS avg_daily_rows
FROM daily_usage
)
SELECT
(SELECT SUM(rows_ingested) FROM daily_usage) AS rows_so_far,
avg_daily_rows,
avg_daily_rows * DAY(LAST_DAY(CURRENT_DATE())) AS forecasted_monthly_rows,
(avg_daily_rows * DAY(LAST_DAY(CURRENT_DATE())) * 0.001) AS forecasted_cost -- assume $0.001 per 1K rows
FROM average_daily;Closing Thoughts
Fivetran is excellent at solving the technical challenge of moving data. But its usage-based billing leaves many teams without the cost transparency they need.
ETL Cost Monitor for Snowflake fills that gap, giving you clear visibility, accurate forecasts, and timely alerts so you can manage costs proactively.
👉 Explore ETL Cost Monitor and bring predictability back to your ETL spend.
Share it with your connections.
-
Share To LinkedIn
-
Share To Facebook
-
Share To X
-
Copy Link
