why product analytics gets expensive, and how to cap the bill

product analytics gets expensive for one structural reason: the big tools price on volume — events tracked, or monthly tracked users — so your bill grows with your success, and it grows fastest right when you can least afford a surprise. a hobby project pays nothing; a product doing 10 million events a month can pay hundreds. the fix isn't a discount code, it's a pricing shape: flat plans with cheap, capped overage, or self-hosting where volume costs you nothing. here's how the pricing actually works and what to do about it.

why does event-based pricing spike?

because events aren't linear with value. every meaningful thing a user does — a pageview, a click you autocapture, a custom event you track — is billable, and a growing product generates events faster than it generates revenue. you add a feature, you instrument it, your event count jumps. you get a traffic spike from a launch, your event count jumps. none of that moved your revenue yet, but all of it moved your bill.

the second-year surprise is the classic version. year one you're under the free tier or on the cheapest paid plan. year two you cross a threshold, the per-event or per-user rate kicks in on your now-much-larger volume, and the invoice doubles. teams routinely describe getting "downgraded" — moved to a smaller cap and losing dashboards and history — because the tool they built on repriced around them.

what does product analytics actually cost at volume?

here's a rough, deliberately conservative picture of monthly cost at 10 million events, using public list pricing. these are estimates — get a real quote to confirm — and they understate rather than overstate:

the pattern is the same everywhere except the bottom two rows: the more you grow, the more you pay, on a curve you don't fully control. there's a live calculator on the pricing page that recomputes these side by side at whatever volume and team size you enter.

how do you make the cost predictable?

three moves, in order of how much they help.

1. self-host. if volume anxiety is the whole problem, self-hosting removes it — your event count costs you nothing because it's your server. the catch is ops weight: self-hosting PostHog means running Kafka, ClickHouse, Redis and Postgres, which is its own project. smolanalytics is one open-source Go binary with no external database, so self-hosting is docker run and done — free, unlimited events, forever. that's the cheapest possible answer if you're willing to run it.

2. move to flat pricing with capped overage. if you want hosted convenience without the volume curve, pick a tool that charges a flat plan and a small, fixed overage. smolanalytics is $29/mo (Solo) to $499/mo (Business), with overage at $5 per extra million events — about a tenth of the hosted-tool rate — and the dashboard never locks or samples when you go over. you get an emailed receipt, not a surprise. the bill moves in small, legible steps instead of a curve.

3. cut the events you don't need. whatever tool you use, a chunk of your event volume is noise — autocaptured clicks you never analyze, debug events, duplicate fires. auditing your tracking plan and dropping what you don't query lowers the bill on any volume-priced tool. (this is also just good instrumentation hygiene; a tracking plan gated in CI keeps it clean.)

the honest tradeoff

flat pricing and self-hosting aren't free lunches. flat plans mean you're not paying for depth you might want later — smolanalytics deliberately doesn't do session replay, feature flags, or experiments, so if you need those, PostHog's usage-priced suite is the better buy even though it costs more at volume. and self-hosting means you run the thing, back it up, and update it. the right answer depends on whether your constraint is money or time. if it's money and you have a little time, self-host. if it's money and you have none, flat hosted pricing. if you need the full experimentation suite, pay for it and budget for the curve.

FAQ

why is Mixpanel so expensive?

Mixpanel prices on event volume, so your bill grows as your product generates more events — which happens faster than revenue grows. the free tier is generous until you cross it, after which the per-event rate applies to your full (now larger) volume, which is why teams describe a sharp second-year increase. flat-priced or self-hosted tools avoid this because the cost isn't tied to your event count.

how much does product analytics cost per month?

it depends entirely on volume and model. at ~10 million events a month, public list pricing puts Mixpanel around $650 and PostHog around $324 (conservative estimates), while a flat-priced tool like smolanalytics is about $124 (a $99 plan plus $25 overage) and self-hosting is free. at low volume most tools are free or near-free; the gap opens as you scale.

is self-hosted analytics actually cheaper?

for event volume, yes — self-hosting removes per-event cost entirely because it's your infrastructure. the real cost moves from dollars to operational time. that trade is cheap when the tool is a single binary (smolanalytics is one Go binary, no database) and expensive when it's a cluster (PostHog needs Kafka + ClickHouse + Redis + Postgres). factor in your own time, not just the invoice.

what happens when I go over my event limit?

it depends on the tool. some sample your data, some lock the dashboard, some bill overage. smolanalytics bills overage at $5 per extra million events with an emailed receipt and never locks or samples the dashboard, so going over is a small predictable charge rather than a broken product. check any tool's overage behavior before you commit — "what happens at 2× my plan" is the question that reveals the real cost.

---

want your exact number? the pricing calculator shows your smolanalytics bill next to PostHog and Mixpanel at your volume. or skip the bill entirely and self-host free.