GrowthBook

What is GrowthBook?

GrowthBook is an open-source experimentation platform founded in 2021 in San Francisco. It provides A/B testing, feature flags, and experiment analysis — and unlike every other major experimentation tool, it does not collect or store your event data. Instead, GrowthBook connects to your existing data warehouse (BigQuery, Redshift, Snowflake, Postgres, MySQL, ClickHouse, Athena) and runs statistical analysis on data that already lives there. This warehouse-native architecture is the core design decision that makes GrowthBook distinctively different from Statsig, VWO, Optimizely, and LaunchDarkly.

The GrowthBook SDK (available for JavaScript, React, Python, Ruby, Go, PHP, Kotlin, Swift, Flutter, and more) handles experiment assignment client-side — it evaluates feature flags and assigns users to experiment variants in the user's browser or app without a network call, making it extremely fast. Results are then analysed by querying your data warehouse directly, which means your experiment metrics can use any event data you are already collecting — not just events you specifically instrument for GrowthBook.

For Indian product teams, this architecture has three practical implications. First, if you are already sending events to BigQuery from your Firebase or Mixpanel setup, GrowthBook can immediately use those events as experiment metrics without re-instrumenting anything. Second, your experiment data never leaves your cloud infrastructure — important for Indian fintech teams with RBI data localisation considerations. Third, there are no per-event fees — GrowthBook's cost does not scale with your event volume the way Statsig's or LaunchDarkly's does.

Key Features

When GrowthBook Beats Statsig and VWO

GrowthBook vs Statsig vs VWO

Best For

• Indian teams with event data in BigQuery, Redshift, or Snowflake who want immediate experiment metrics
• Regulated Indian fintech and healthtech teams with data localisation or sovereignty requirements
• Engineering-led teams replacing LaunchDarkly with a free self-hosted feature flag solution
• Startups where paid experimentation tools are cost-prohibitive and engineering can support a Docker deployment
• Teams wanting Bayesian statistics and CUPED variance reduction without paying enterprise tool pricing

Pricing

GrowthBook has two deployment options: self-hosted (free) and GrowthBook Cloud (SaaS). The self-hosted option is fully featured — not a limited community edition.

Pros and Cons

Alternatives to GrowthBook

Getting Started with GrowthBook

1. Choose self-hosted vs cloud before anything else — The self-hosted vs cloud decision shapes your entire setup path. Choose self-hosted if: your data cannot leave Indian infrastructure, you have a DevOps engineer who can manage Docker deployments, and cost efficiency is a priority. Choose GrowthBook Cloud if: you want to start experimenting this week without infrastructure setup, you are a solo PM or small team, or you want managed reliability without operational overhead. Do not try to defer this decision — the SDK integration and data connection steps differ between the two options.
2. Self-hosted: deploy with Docker Compose in under an hour — GrowthBook's official Docker Compose file spins up the full application in one command. Deploy to an AWS EC2 t3.small (ap-south-1 for Indian data residency) or GCP e2-small. Point your domain at it, configure SSL, and set your MongoDB connection. The total setup time for an engineer familiar with Docker is 45-90 minutes. GrowthBook's documentation covers this step-by-step — follow it exactly and you will have a running instance before lunch. The most common mistake is skipping the reverse proxy setup, which causes HTTPS issues when embedding GrowthBook in your workflow.
3. Connect your data warehouse before creating your first experiment — GrowthBook's analysis depends on a data source connection. In the Data Sources section, connect to your BigQuery project, Redshift cluster, or Snowflake account. Then define your identifier types (user_id, anonymous_id, device_id) and map them to your event tables. Finally, define 3-5 metrics from your existing event data — your primary activation event, your retention signal, and any revenue metric. This setup takes 2-3 hours the first time but means every experiment you create from that point uses your real product data with zero additional instrumentation.
4. Install the SDK and use feature flags for your first experiment — Start with a simple feature flag experiment before attempting complex multivariate tests. Install the GrowthBook SDK in your codebase (npm install @growthbook/growthbook for React), initialise it with your features endpoint, and wrap one UI element in a feature flag. Run the experiment at 50/50 with your primary metric as success criteria. This first experiment teaches your team the GrowthBook workflow — flag creation, SDK integration, metric definition, and result reading — without the stakes of a critical feature test. Run it for 2 weeks regardless of early results.
5. Set a minimum experiment runtime policy before launching experiments — The most common experimentation mistake at Indian startups is stopping experiments early because results "look good." This peeking inflates false positive rates significantly — you will ship changes that appear to work but do not. Before running your first experiment, agree on a team policy: experiments run for a minimum of 2 weeks and a minimum of the sample size calculated from your expected minimum detectable effect. Write this in your team wiki. Use GrowthBook's sequential testing feature if you need valid early stopping — it is statistically sound whereas manual peeking is not. Enforce this policy even when leadership asks why an experiment is still running.