GrowthBook Review 2026: Pricing, Features, Real Limits

GrowthBook is the most serious option in the category for a team that wants to audit its own statistics, and the price of that is not in the license: it is in needing a data warehouse and someone who writes SQL. It is an open-source feature flagging and experimentation platform with a warehouse-native architecture, meaning it reads data where it already sits rather than copying it to a vendor server. This review covers what it does well, what it charges, where the real limits are, and what kind of operation that math works for. For the wider landscape, see our comparison of open-source A/B testing tools.

A disclosure before anything else: Donnu is an A/B testing tool and competes with GrowthBook on part of this scope. This review was written to be useful even to a reader who picks GrowthBook at the end, which is exactly why the section on where it is clearly the right call exists.

What GrowthBook Is, One Line Per Piece

Piece	What it does	Who tends to care
Feature flags	Controlled feature release and rollout through SDKs	Engineering and product
Experimentation	A/B and A/B/n tests wired to the same flags	Product, growth, and engineering
Warehouse-native layer	Queries metrics directly in your data warehouse	Data, compliance, and finance
Statistics engine	Bayesian and frequentist, with sequential testing and CUPED by tier	Whoever reads the result and approves the rollout
Visual editor	Building a variation without a deploy (paid plans)	Marketing, where it exists

Choosing between GrowthBook and a closed commercial tool is rarely about the quality of the A/B test itself. It is about where your data lives and who can touch it. Teams that already have a warehouse, a modeling layer, and a data function find real savings here plus a level of auditability closed tools do not offer. Teams that do not are buying an infrastructure project alongside the tool, and that project usually costs more than the license it saves.

Pricing: Unlike the Category, There Is a Public Table

This is where GrowthBook separates itself from most competitors: the numbers are published. According to the official pricing page checked on 13 August 2026:

Path	Price	What is included
Open source, self-hosted	Free	Unlimited users, flags, and experiments on your infrastructure, 1 project, community support, no advanced features listed
Cloud Starter	Free	Up to 3 users, 1 project, unlimited flags and experiments, bring your own warehouse
Cloud Pro	$40 per seat per month	Up to 50 users and 3 projects, visual editor, multi-arm bandits, safe rollouts, advanced permissioning, power calculator, sequential testing, CUPED, premium support
Enterprise (cloud or self-hosted)	Custom	SSO with custom OIDC and SCIM, exportable audit logs, approval workflows, ramp schedules, 99.99% uptime SLA, dedicated support

Per-seat pricing has a management consequence worth anticipating: it penalizes the “everyone gets read access” model. In a mature experimentation program, a lot of people need to see results without configuring anything, and in a per-seat model each of those people costs. Design the access policy before contracting, not after.

And the most important caveat in this section: free does not mean free of cost. The open-source edition is honestly free, but running it means maintaining a server, keeping it patched, and paying for warehouse queries, which are not cheap on large datasets. Add the time of whoever models the metrics in SQL and the real number appears. That is not a criticism of the product, it is the nature of the choice: you trade a subscription for control and internal work.

Warehouse-Native: What Changes When the Metric Is Your Own Query

In a traditional tool, the script collects events and sends them to the vendor database, which computes and returns the report. In the warehouse-native model the path is different: the events already sit in your data warehouse, and the tool generates SQL queries against it to produce the numbers.

Three practical consequences, all verifiable:

• No data duplication. You do not pay to store the same thing twice, and you do not reconcile two sources that disagree.
• Definition reuse. If “active user” is already defined in your model, the experiment uses that definition rather than a parallel one invented inside the tool.
• Real auditability. The platform exposes the SQL behind every number, so the data team can reproduce, audit, and debug a strange result without filing a support ticket.

The third point is what most separates this tool from closed competitors. On nearly every commercial platform, when the number looks wrong, the path is a support ticket. Here, the path is reading the query.

And then the honest trade-off appears: whoever writes the query decides the result. That is not a defect, it is a transfer of responsibility, and it is large enough to deserve this review’s entire worked example.

The Worked Example: Same Data, Two Denominators, Two Different Tests

A store tests a change to a block on the product page. Important detail: only about 40% of visitors scroll far enough to see that block. The other 60% are never exposed to the change, but they keep landing on the page and buying at a 1.5% rate.

Among the exposed, the change works: the rate rises from 7.5% to 8.4%, a 12% relative gain. Now the two ways to write the metric in SQL:

Definition 1, “all page visitors”: the overall control rate is 0.4 times 7.5% plus 0.6 times 1.5%, that is 3.90%. The variation is 0.4 times 8.4% plus 0.6 times 1.5%, that is 4.26%. The relative gain falls to 9.23%, because 60% of the sample could not move.

Definition 2, “only those exposed to the block”: 7.5% against 8.4%, a 12% relative gain, the real effect with no dilution.

The sample each definition requires, at 95% confidence and 80% power:

SQL metric definition	Baseline rate	Effect to detect	Sample per variation	Weekly traffic available	Duration
All page visitors	3.90%	+9.23% relative	47,410	30,000	23 days
Only those exposed to the block	7.50%	+12.00% relative	14,182	12,000	17 days

Sample by normal approximation of two proportions, 95% confidence, 80% power, two-sided; duration for 2 variations.

Run both rows yourself:

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 diluted definition needs 3.3 times more people per variation to prove the same real effect. And note the detail that usually goes unseen: because the exposed segment also has less weekly traffic, the calendar difference is far smaller than the sample difference, 23 days against 17. It is not a spectacular time saving, it is a saving in power: with the same window, the exposed read detects effects the diluted read would let pass as a tie.

Now the observed read. Suppose the test ran the 23 days the stricter definition required, accumulating roughly 49,000 visitors per variation on the page, of whom 19,600 per variation were actually exposed to the block. The same events, read both ways:

Read	Visitors per variation	Conversions A	Conversions B	z score	p-value	Verdict
All visitors	49,000	1,911 (3.90%)	2,087 (4.26%)	2.84	0.0045	Significant, B wins
Only exposed	19,600	1,470 (7.50%)	1,646 (8.40%)	3.29	0.0010	Significant, B wins

Check both rows in the calculator:

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.

The two reads agree, and that is what usually happens when the effect is large enough and the test ran to completion: the diluted denominator gets there, it just spends far more people doing it. The danger lives in the neighboring and more common case, the smaller effect: had the diluted read stopped at the sample that suffices for the exposed read (19,600 per variation), its statistical power would have been only 43.7%, meaning less than half a chance of detecting an effect that genuinely exists. In that scenario the same change gets filed as “did not work” because of a SQL choice.

The practical conclusion is not “always measure only the exposed”. The two reads answer legitimate and different questions: the exposed read answers “does this change work for the people who see it”, and the diluted read answers “does this change move the number for the whole page”. The rule is to choose which question you are asking before running, record that choice with the hypothesis, and never switch denominators after seeing the result. Our guide to writing an A/B test hypothesis has a format that makes the record natural.

GrowthBook Review: Real Strengths

• Auditability with no equivalent in the category. Being able to read the SQL behind every number turns a trust argument into a technical argument, which is solvable.
• Both statistical schools documented. Bayesian and frequentist engines, with sequential testing and CUPED available on the Pro tier, cover the methods a serious program needs.
• Public pricing. In a category where almost everyone hides the number behind a call, publishing a table is a concrete advantage in evaluation time.
• No data duplication. For operations with compliance requirements about where user data lives, the warehouse-native model solves by architecture what other tools solve by contract.
• Flags and experiments in one tool. It avoids the seam between two platforms, which is where instrumentation usually breaks.

Limitations and Watch-Outs

• It requires a warehouse and SQL. This is the filter that decides most cases. Without a working warehouse and someone comfortable with queries, the tool does not move.
• Real cost outside the license. Infrastructure, warehouse queries, and modeling time. Comparing license against a commercial suite is comparing different things.
• The metric is your responsibility. As the example above shows, a poorly chosen denominator produces a valid test that answers the wrong question. A closed tool hides that decision; here it is yours, with the upside and the downside of that.
• Advanced statistics are tiered. On the pricing page checked today, CUPED and sequential testing sit under Cloud Pro, while the open-source self-hosted row lists no advanced features. If variance reduction is what makes your low-traffic program viable, confirm it is included in the plan you are actually buying.
• It is not a behavior suite. It does not replace heatmaps, session recording, or user research. If you need the hypothesis before the test, you need another tool alongside it.
• Per-seat pricing penalizes broad access. In a mature program many people only need to read the result, and in a per-seat model that costs.

How to Evaluate GrowthBook in a Pilot

Check	How to do it	What it reveals
Query cost	Run a test experiment and measure warehouse query cost for a week	The invisible monthly bill of the warehouse-native model
Metric definition	Write the same metric with two denominators and compare results	Whether the team understands the impact of the choice before deciding with it
Real traffic split	Run an A/A test for a few days and verify the proportion	Whether variation assignment is stable and free of sample ratio mismatch
Report latency	Time how long an event takes to reach the dashboard	Whether the team’s decision rhythm fits the data pipeline’s rhythm
Who can operate it	Ask a non-technical teammate to build and read a test alone	Whether the tool serves the whole team or only the data function

The last row is the most decisive and the least tested. A tool only the data team can operate turns every marketing experiment into an internal request, and an internal queue is the most expensive form of organizational friction, as our guide to building an experimentation culture details.

The A/A test in the third row deserves its own note: both variations are identical, so any “winner” that appears is noise by definition. It is the cheapest audit that exists, and it is worth running on any tool you are evaluating, including ours.

Who GrowthBook Is For

It fits teams that already have a data warehouse in use and someone comfortable with SQL, operations that must keep data on their own infrastructure for compliance or cost, engineering teams that want feature flags and experimentation in one tool, and anyone who wants to audit the statistics rather than trust a winner badge.

It fits less well for a marketing team without data support, for anyone who needs to start testing this week without opening an infrastructure project, and for teams that need heatmaps, session recording, and user research in the same platform, a scenario covered in our comparison with commercial suites.

If your case is the second one, Donnu is one of the lighter options in the category, with predictable pricing, no call to learn the number, and no warehouse or SQL required to start. It does not replace GrowthBook on warehouse-native architecture, SQL auditing, self-hosting, or SDK feature flags, and saying otherwise would be dishonest: if you need those pieces, Donnu is not the right comparison. If you do not, start a free trial and compare what actually matters for your case.

---

Read also: GrowthBook vs Statsig · Open-source A/B testing tools · What is CUPED · Sequential testing explained · Leia em português

References

• GrowthBook. Pricing. Plans, per-seat price, user and project limits, and the scope of each tier including the self-hosted open-source edition, checked on 13 August 2026. growthbook.io/pricing.
• GrowthBook. Experimentation and A/B testing platform. Official product page, with the description of the warehouse-native architecture and the statistics engines. growthbook.io/products/experimentation.
• GrowthBook. Connecting to your data warehouse. Documentation listing the supported warehouses for direct querying. docs.growthbook.io/warehouses.
• Deng, A., Xu, Y., Kohavi, R. and Walker, T. Improving the Sensitivity of Online Controlled Experiments by Utilizing Pre-Experiment Data. WSDM, 2013. The original CUPED paper. exp-platform.com.
• Kohavi, R., Tang, D. and Xu, Y. Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Cambridge University Press, 2020. Chapters on metric definition, dilution, and statistical power. Companion material at experimentguide.com.