Fivetran Pricing - Poor Execution or Smart Value Extraction?
🧐 Something MARring your ETL experience?
If you follow me on LinkedIn, you know I am often critical of Fivetran’s pricing. They have conveniently made this criticism easy by making frequent and unpopular changes to the model.
As a founder, I am somewhat sympathetic. You have to run a business, and it’s important to try to align your pricing with the value that your customers get from your product.
As a customer advocate, I’m happy to criticise as their pricing hasn’t been great for customers, particularly in their traditional sweet spot of mid-market companies.
As a competitor, I love it because they’ve made some particular missteps which have made criticism particularly easy.
I was reminded of all of this last week when I saw a surprising post from Ivan Stegic praising Fivetran for their pricing changes.
This was surprising to me, I’ve spoken to a lot of Fivetran customers in the past few months and most had their bills go up 50 %-60 % and some as much as 2-4X. What is going on🤔? I think I have an answer, read below.
Before we dig into the latest change, let’s look at the history of Fivetran’s pricing. I'll try to assess each model based on the customer's and Fivetran's perspectives.
2012-2020 - Startup Era
Fivetran was founded in 2012 when the dominant model for SaaS was subscription based. Naturally, they aligned to this and initially offered a subscription based on the number of connectors being used with no limitations on actual consumption within those models.
Customer Perspective:
Pros: Very predictable pricing, very attractive for high volume connectors
Cons: Relatively expensive for low volume connectors, incentivises not bringing those low volume connectors onto the system. Not a good fit in general if a customer has a large number of low-volume connectors
Fivetran Perspective:
Pros: Predictable revenue from customers, potentially easier justification of R&D on new connector builds given fixed revenue commits
Cons: This pricing model violated two very basic principles of pricing, you shouldn’t sell things for less than they cost and pricing should be aligned to the value your customers get from the product. On the first point, you could imagine a customer could have a single database connector with multiple TB of data driving real operational cost for Fivetran and the customer is only paying $150/month for that connector. That same customer is clearly deriving much greater value from those TBs of data being moved so they would presumably pay more than $150/month. On the other hand, as discussed earlier, that customer might have a hard time justifying adding their HR platform to Fivetran because it is low volume and not worth paying $150/month for.
So, if I’m George Fraser, Fivetran’s CEO, in 2020. What do I see? I have a fast-growing business. My partnership with Snowflake is going well, and we’re riding along with their explosive growth. But my pricing is broken.
At the same time, usage-based pricing is growing in popularity. Twilio and others established in the mid-2010s that usage-based pricing worked well, and Snowflake had clearly established that it would work in the data world.
Customers liked it, at least initially, and it solved the two key problems above. Assuming you chose the correct metric for usage, when customers used more, they would get more value and be happy to pay more. Relatedly, you could ensure you were always charging enough to maintain good margins.
At this point, I think Fivetran made the correct decision to move to usage-based pricing. It was HOW they did it that caused issues for them.
2020-2021 - Enter MAR (monthly active rows)
The now infamous MAR enters the chat. Monthly Active rows, or MAR, measures the number of unique primary keys (rows) that are added, updated, or deleted from a customer's source systems and synced to their destination by Fivetran connectors within a given month. On the surface this seems like a customer friendly approach to usage-based billing but it was not well received.
Customer Perspective:
Pros: Incentive to bring all data sources/connectors to Fivetran even if tiny volume.
Cons: No more free rides for high volume connectors. Lack of predictability in costs. Unexpectedly high costs. MAR itself is confusing and expensive relative to the other popular SaaS ETL tool at the time, Stitch. In particular due to the following:
Data Normalization: Fivetran's process of normalizing data, especially from sources with nested or semi-structured data (like JSON), could significantly inflate the MAR count. A single record at the source might be transformed into multiple rows in the destination warehouse, each potentially counting towards MAR.
Frequent Updates: Any update to an existing row, no matter how minor, would typically count that row as active for the month. For data sources with high update frequencies, this could lead to substantial MAR counts.
Historical Syncs: While initial historical syncs for new connectors were often free, any subsequent large-scale re-syncs or historical backfills could generate significant MAR.
Fivetran Perspective:
Pros: Better alignment to operational costs and customer value
Cons: Negative customer reaction while new competitors emerging, unique branding (MAR) of an unpopular change, potentially poor alignment to R&D effort, e.g. it’s harder to justify building and maintaining a new connector that will be low volume
Fivetran likely made the right choice moving to usage-based pricing, but the specific execution turned them from a well-loved tool to one which customers begrudgingly used because alternatives were lacking.
With MAR, Fivetran tried to create its own proprietary pricing that was similar to Stitch but not directly equatable. Rather than tracking total rows ingested, MAR tracked net new rows. Their argument was that these net new rows were the ones that actually added value.
The problem for customers was it was not as transparent and straightforward to measure or compare for the reasons highlighted above. Stitch had its own problems but most of the folks I spoke to back in those days tended to prefer Stitch’s pricing model, which was to simply count all rows processed (new or otherwise) and to charge a lower rate for them.
2021-2022
There was no fundamental change in this period, but execution, how discounts are handled, and the lack of transparency of MAR continued.
2023
New tiers introduced, MAR is still the backbone. More historical discounts are being removed and upsetting customers:
Competitors like streamkap.com are maturing and allowing for faster and cheaper data replication.
2025
Now we come to this year. Fivetran is now over $300M in revenue, and as I wrote about earlier this year, likely pursuing an IPO soon. This is important context.
Late last year, I heard from some larger customers that Fivetran was offering an all-you-can-eat package. That sounds compelling; tell me more. The trick was that this was typically 50-100% more expensive than the customer was currently paying. How do you get them to accept that increase? You make them feel the pain of not taking it with increasing complexity in a sort of pincer move…
Connection-based pricing:
Fivetran moves from an aggregate MAR measure across all of your connectors to counting MAR and discounting MAR at a connection level. It’s not immediately clear what this means for individual customers. Things just got even more complicated.
Fivetran was quick to point out that most of their customers save money, and I take them at face value that this is true. However, there is a VERY important caveat here.
Fivetran has several thousand customers, how many of those customers do you think look like Ivan, who I quoted above? I would imagine there is a long tail of thousands of customers paying a few hundred dollars a month. Fivetran will happily save those customers 30 %-40 % on average because those customers don’t matter to their overall revenue.
Fivetran is trying to go public. They are not going to introduce a pricing change that is going to produce a smaller total amount of revenue across their customer base. Fivetran needs to drive more large accounts. So, they are moving up market. They are charging more money to their mid-market and enterprise customers. This is where the pincer move comes in.
You make the pricing more complicated and expensive for your customers paying $36k+ per year, but you offer them a way out of the complexity. Oh, and you won’t have to worry about those pesky MAR on your $100k bill if you just pay us $200k for an unlimited plan.
So if you’re a mid-market or enterprise company. Expect the squeeze to come. You are the cash cow paying for those long-tail customers like Ivan.
If you’re looking for an alternative where you can get faster, more reliable, more transparently and simply priced platform, check us out at streamkap.com or reach out to me directly.
Warmly,
Paul Dudley
You have the big picture of what changed when and why right.
You misunderstand the implications of MAR a little bit. MAR is strictly lower than total rows in every situation. The effect of MAR is it acts as an "emergency brake" when you have a small table that is getting thrashed by tons of updates. Using MAR instead of total rows or events stabilizes the entire system and makes it more predictable.
You are correct that the customers that go up tend to be larger, but whether you believe me or not, this change is expected to overall decrease revenue a little bit. We forecasted a ~5% headwind from the change in our annual budget.
You also missed that we introduced automatic resync detection, which solves this problem that you mentioned: "any subsequent large-scale re-syncs or historical backfills could generate significant MAR."
Overall, this change is not really an increase or a decrease in the customers as a whole. It's a collection of "fixes" that address various illogical corner cases in pricing. It was calibrated to be approximately revenue neutral---it was actually calibrated by a Python parameter sweep!