PostHog Review 2026: Features, Pricing, and Real Costs

PostHog is not an A/B testing tool, it is a product platform where A/B testing is one of the modules, and understanding that difference settles most of the questions people bring to an evaluation. You do not buy PostHog to test a landing page; you adopt PostHog to instrument a product and, along the way, you get experimentation tied to the feature flags you already use. This review covers what it does, what it actually charges per unit, how much of the free allowance a real test consumes, what self-hosting gives you, and who the arithmetic works for. For the category picture, see our neutral comparison of CRO and A/B testing tools.

Disclosure before anything else: Donnu is an A/B testing tool and competes with PostHog on part of this scope. This piece is written to be useful even to a reader who ends up choosing PostHog.

What PostHog is, one line per piece

Piece	What it does	How it is billed
Product analytics	Events, funnels, retention, cohorts	Per event, starting at 0.00005 dollars
Session replay	Playback of behavior on web and mobile	Per recording, starting at 0.0050 dollars on web
Feature flags	Turns functionality on and off per segment	Per request, starting at 0.0001 dollars
Experiments	A/B testing built on top of the flags	Billed together with feature flags
Surveys	In-product questions	Per response
Error tracking	Exception capture	Per exception

The honest read of that table: the experiment has no price of its own. It rides along on feature flag billing, which is a modeling decision with a strong practical consequence, covered in the cost section below.

Pricing: a free allowance per product

There is no entry subscription. Each product has its own monthly free allowance and, above it, you pay per unit consumed, at a price that falls by volume tier (hence the “starting at” on every line). Numbers checked on the official page on 14 August 2026:

Product	Monthly free allowance	Price above the allowance
Product analytics	1 million events	From 0.00005 dollars per event
Session replay (web)	5,000 recordings	From 0.0050 dollars per recording
Feature flags and experiments	1 million requests	From 0.0001 dollars per request
Surveys	1,500 responses	Per response, by tier
Error tracking	100,000 exceptions	Per exception, by tier

The strategic implication of that model is that an entire small operation runs free, indefinitely, with no contract and no sales call. That is rare in this category and it is the main reason PostHog shows up so often in lists of free A/B testing tools and open-source A/B testing tools.

What an A/B test actually consumes

This is where the review earns its keep. Because the experiment is billed as a feature flag, the cost of testing depends on two things you control: how often the flag gets evaluated, and how many events your instrumentation fires.

Set the calculator to your own baseline rate to size your case:

Current conversion rate%Minimum detectable effectrelative (%)absolute (pp)Confidence909599%Power8090%Visitors per week (total)Testtwo-sidedone-sided

-Visitors per variation

-Total (2 variations)

-Estimated duration

Two-proportion normal approximation, 2 variations (50/50). Tweak the inputs and watch it update live.

The worked example

A product converts 2.5% of visitors on a measured action and gets 25,000 visitors per week into the tested flow. To detect a 12% relative lift (2.5% to 2.8%) at 95% confidence and 80% power, the math asks for 44,996 visitors per variant, which takes 26 days. Aiming at 20% relative instead (2.5% to 3%) drops the requirement to 16,792 per variant and closes the test in 10 days.

The 26-day test involves roughly 90,000 visitors across both variants. Assume 4 pages per visitor with a flag evaluation on each, 12 analytics events per visitor, and recording of 10% of sessions. The month works out like this:

Consumption line	Experiment volume	Free allowance	Overage	Cost
Feature flag requests	~360,000	1 million	None	0 dollars
Analytics events	~1.08 million	1 million	~80,000	~4 dollars
Session recordings	~9,000	5,000	~4,000	~20 dollars

Total cost of the experiment’s month: about 24 dollars, and notice where it comes from. The expensive part is not the test, it is session replay. The flag requests, which are what PostHog counts as the experiment’s cost, never even left the free allowance. A team looking to spend less should not cut the statistical ambition of the test, it should cut the sampling rate of its recordings.

Reading the result

Say the test ran to 45,000 visitors per variant and closed with 1,125 conversions on control (2.50%) against 1,233 on the variation (2.74%).

Control (A)

VisitorsConversions

Variation (B)

VisitorsConversions

Confidence90%95%99%

Control (A) · Rate-

Variation (B) · Rate-

Relative lift-

p-value-

95% CI of the difference-

Two-sided two-proportion z-test. "Not significant" almost always means not enough sample, not that the versions are equal.

Running those four numbers through this blog’s significance engine: z = 2.25, p-value ≈ 0.0242, with a 95% confidence interval on the difference of +0.03 to +0.45 percentage points, and an observed relative improvement of +9.6%. It is significant against the 5% bar, and the interval is still wide enough that a revenue projection should be built from the lower bound rather than the point estimate, as our statistical significance guide spells out.

One trap specific to platforms where the experiment is born from a feature flag deserves a note, because it costs data rather than money: evaluating the flag is not the same as exposing the visitor to the variation. If your code asks for the flag value on every page load, including pages that never render the tested element, the experiment’s denominator starts including people who never saw the difference. The measured effect shrinks, the test needs more sample for the same power, and the read turns conservative without anyone noticing. The practical rule is to log exposure at the moment the tested element actually renders, not at the moment the flag is queried. It applies to any tool with this design, and it is exactly the kind of defect an A/A test will not catch, because there both sides are identical by construction.

What the invoice looks like as you grow

Usage-based pricing is easiest to judge by projecting it at three stages rather than at one. Using the published starting rates and the same instrumentation assumptions as above (12 analytics events per user, 4 flag evaluations per user, 10% session sampling), a rough monthly shape looks like this:

Stage	Monthly users in product	Analytics events	Flag requests	Recordings	Rough monthly cost
Early startup	20,000	~240,000	~80,000	~2,000	0 dollars, entirely inside the allowances
Growing product	150,000	~1.8 million	~600,000	~15,000	Tens of dollars, driven by events and recordings
Scaled product	1,000,000	~12 million	~4 million	~100,000	Hundreds of dollars, and volume tiers start mattering

These are order-of-magnitude projections from published starting rates, not a quote, and the per-unit price falls by tier as volume grows, so the bottom row is the pessimistic reading. The point of the exercise is the shape rather than the exact figure: the free tier is not a teaser, it genuinely absorbs an early-stage product, and the first line to breach it is almost always session replay rather than experimentation. Set a consumption alert at the point where you would want to be told, and revisit the recording sampling rate at each stage rather than once at setup.

Self-hosting: what it is and what it is not

This is the most misunderstood part of the product. The self-hosted deployment exists, is distributed under an MIT license, and anyone can stand one up. According to the official documentation, however, it is officially unsupported, carries no guarantee of function or performance, and only gives access to free-tier features: everything on a paid plan stays cloud-only. The documentation itself recommends the cloud for most users and reserves self-hosting for teams with a specific data privacy requirement or deep infrastructure capability.

The practical translation: self-hosting here is a data sovereignty option, not a savings option. Whoever runs their own instance takes on operations, upgrades, and risk to end up with the same feature set the cloud already gives away inside the free allowance. It makes sense for teams under a regulatory or data policy constraint that forbids sending events outside; it does not make sense as a cost-cutting strategy.

Real strengths

• A free allowance that covers a whole operation. A small product runs analytics, replay, flags, and experiments spending nothing, with no contract.
• Experiments with no price of their own. Teams with many small tests do not pay per experiment, which removes the bad incentive of hoarding tests to justify a subscription.
• Everything on the same events. The experiment’s number and the analytics number come from one source, which eliminates the classic divergence between two screens.
• Published per-unit pricing. You can project the invoice from your own volume, without a quote.
• MIT-licensed code available. Even with the self-host limitations, being able to read the code is a real audit and exit argument.

Limitations and watch-outs

• Not a marketing tool. With no visual editor as the primary path, testing a page without a developer is friction, and the marketing team ends up dependent on the engineering queue.
• Variable invoice. Usage-based pricing is excellent when volume is small and unpredictable when the product grows fast. Set consumption alerts before, not after.
• Session replay dominates cost. As the example shows, it is the line that breaches first, and it is easy to leave switched on for 100% of sessions by accident.
• Self-hosting with reduced scope. Unsupported and limited to the free tier, it is not the paid version running on your infrastructure.
• Breadth charges a learning curve. A platform with more than ten products demands discipline not to instrument everything and then pay for data nobody looks at.

How to evaluate it in a pilot

1. Instrument only what feeds a metric. Events per user is your main cost lever.
2. Set the recording sampling rate on day one. Recording 10% usually answers the same questions as recording 100%, for a tenth of the price.
3. Run an A/A test. Confirm traffic splitting matches what you configured and that the tool correctly reports the absence of an effect.
4. Project the invoice from your peak, not your average. Usage-based pricing rewards you in the trough and surprises you at the peak.
5. Confirm the allowances on the official page. Tier limits and prices change, and the value of this article is the date it was checked, not a permanent promise.

PostHog review: final analysis and who it is for

It fits product and engineering teams that want analytics, replay, flags, and experimentation in one place, with variable cost and a genuinely free start. For an early-stage startup, the combination of a generous allowance, no contract, and available source code is hard to beat.

It fits less well for marketing teams that need a visual editor to test landing pages without a deploy, for organizations that require a fixed, predictable invoice, and for anyone expecting self-hosting to be a free copy of the paid product. For direct comparisons inside the same family, see PostHog vs VWO and our Statsig review, which solves a similar problem with a different billing model.

If your case is testing web pages with statistical rigor and without standing up an entire product platform, Donnu is a lighter option, with predictable pricing and a conservative read of the result. It does not replace PostHog for product analytics, session replay, surveys, or error tracking, and saying otherwise would be dishonest. If all you need is the testing part, start a free 14-day trial.

---

Read also: CRO Tools Compared · PostHog vs VWO · Open-Source A/B Testing Tools · Feature Flag Tools Compared

References

• PostHog. Pricing. Monthly free allowances per product, per-unit prices above the allowance, and the note that Experiments is billed with feature flags, checked on 14 August 2026. posthog.com/pricing.
• PostHog. Self-host. MIT license, absence of official support, limitation to free-tier features, and the explicit cloud recommendation for most users. posthog.com/docs/self-host.
• PostHog. Experiments. Documentation of the experimentation module built on top of feature flags. posthog.com/docs/experiments.
• Kohavi, R., Tang, D. and Xu, Y. Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Cambridge University Press, 2020. Chapters on instrumentation, A/A testing, and platform choice. Companion material at experimentguide.com.