Discussion about this post

User's avatar
George Fraser's avatar

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!

Expand full comment
1 more comment...

No posts