Statsig alternative: when Statsig fits and when GrowthBook fits
If you are reviewing Statsig after the OpenAI and Amplitude ownership changes, the short answer is this: Statsig fits teams that want a hosted product, event-based pricing and vendor-run infrastructure, while GrowthBook fits teams that already run a data warehouse, need experiment data to stay in their own environment and have staff to operate the platform. Neither option is the right default for every organization, so the decision should rest on specific facts rather than on the vendor's brand or the size of the company. Statsig's own documentation describes warehouse native deployment as part of its Enterprise plan, so a team that needs warehouse-resident data without Enterprise pricing has a reason to look at GrowthBook early.
Before you decide, confirm several things in writing. Ask Statsig which plan includes warehouse native deployment, SSO, role-based access and HIPAA eligibility, and whether those terms survive the Amplitude acquisition recorded on Statsig's blog. Estimate your monthly analytics event volume, because Statsig bills on events and that number drives its cost. On the GrowthBook side, check whether the self-hosted Open Source plan covers your project count, since it allows one project, and whether you need the Enterprise features listed on the GrowthBook pricing page, such as SSO and SCIM, approval workflows and holdouts. Your warehouse team should also confirm that read-only access is acceptable for experiment queries. The decision turns on four questions: who owns the warehouse, which Enterprise features you cannot do without, how many events you expect to process, and who will operate the platform after launch. If a hosted vendor will run the platform and you do not want to own uptime, upgrades or database administration, Statsig is the simpler path. If your data already sits in Snowflake, BigQuery or another supported source, you have the staff to run a self-hosted stack, and you want experiment computation to stay inside your environment, GrowthBook deserves a structured pilot before you commit to renewal terms.
Which option fits which scenario
This table matches common Statsig replacement scenarios to the GrowthBook option that fits best and the condition that decides it. Read each row against your own warehouse, identity, approval and support needs, and remember that the self-hosted Open Source plan allows one project with unlimited users.
| Scenario | Better fit | Deciding condition |
|---|---|---|
| Existing Snowflake or BigQuery warehouse | Self-hosted GrowthBook | GrowthBook queries your warehouse with read-only SELECT statements and returns only aggregates, so you avoid paying for a Statsig warehouse native tier on Enterprise. |
| Need for SSO, SCIM and approval workflows | Self-hosted GrowthBook Enterprise | SSO, SCIM, advanced permissioning and approval workflows are listed on the paid self-hosted Enterprise tier, not the free Open Source plan. |
| Small team wanting free self-hosting | Self-hosted GrowthBook Open Source | Free with unlimited users, but limited to one project, so it suits a single product area. Confirm the project count against your roadmap before committing. |
| Team that needs vendor support | Confirm with each vendor before choosing | Support tiers are tied to paid plans. Ask GrowthBook and your Statsig account team for written support terms, response commitments and escalation paths. |
| Team planning an exit after the Amplitude acquisition | Self-hosted GrowthBook, after a parallel run | Use the documented Statsig importer to move gates, configs and experiments, then validate results in a parallel run. Review your Statsig contract for termination and data return terms first. |
| Several products or more than one project | Self-hosted GrowthBook Enterprise or another platform | The free plan's single project limit becomes the constraint. Compare paid Enterprise terms with Unleash or Flagsmith for flag-only needs. |
Where your experiment data lives and who controls it
The main difference between Statsig and self-hosted GrowthBook is where event data sits during analysis. Statsig is vendor-hosted, with warehouse native deployment on its Enterprise plan, while GrowthBook queries your own sources and returns only aggregates. The cards below cover the data path, the stack you would operate, and the identity and evidence work that follows.
How the query path works
GrowthBook connects to your own sources, including BigQuery, Snowflake, Redshift, Databricks, Postgres and Trino, and runs only SELECT queries against them. It transmits only aggregated statistics back to the application, so raw event rows stay in your warehouse. Confirm with your data team which tables and schemas the GrowthBook service account can read, and whether any experiment metric needs row-level data outside that boundary.
Statsig's vendor-hosted model
Statsig runs as a vendor-hosted service, and its pricing page lists warehouse native deployment as part of the Enterprise plan. Teams on the standard plans therefore send event data to Statsig's hosted platform for analysis. Ask Statsig, in writing, where your event data is stored and processed, which regions apply, and how the ownership changes affect your contract terms.
The GrowthBook application stack
GrowthBook ships a Next.js front end, an Express API and a Python statistics engine in a single Docker image. Metadata such as flags, users and experiment definitions goes to MongoDB or a compatible database, and the documentation suggests a managed service such as MongoDB Atlas or AWS DocumentDB for production. Plan backup, encryption and patching for the metadata store as a separate workstream from the application.
Kubernetes and file storage options
GrowthBook maintains an official Helm chart for Kubernetes deployments. File uploads can go to local storage, Amazon S3 or Google Cloud Storage, which affects where uploaded artifacts sit and who can access them. Decide early which storage location your data classification allows, and confirm that the chosen bucket or volume has the same encryption and access logging as your other production data.
Identity and access controls
On self-hosted GrowthBook, the free Open Source plan does not include SSO, SCIM, advanced permissioning or approval workflows, which the Enterprise tier adds. Without SSO, user lifecycle and role changes must be managed inside GrowthBook itself. Map who can edit flags, change metric definitions and view experiment results, and decide whether SSO and SCIM are required before production use.
Audit evidence and the auditor's role
Self-hosting moves logging, retention and access reviews into your environment, so you own the evidence trail for experiment data. DeployOpen can plan, implement and document controls and collect evidence for your compliance assessment, but it does not issue audit reports or attestations. Independent auditors and certification bodies make that determination, so confirm with them which controls and evidence formats they will accept before the build starts.
Licensing and editions: what you get for free and what you pay for
GrowthBook sells hosted plans that run on its own cloud, and the price structure is what most teams compare first. The pricing page lists Cloud Starter as free for up to 3 users and 1 project. Cloud Pro is priced at $40 per seat per month (per GrowthBook's pricing page) for up to 30 users and 3 projects. Enterprise is quoted on a custom basis.
- Cloud Starter: free, limited to 3 users and 1 project, suited to small evaluations.
- Cloud Pro: $40 per seat per month, up to 30 users and 3 projects, billed on seats rather than events.
- Enterprise (hosted): custom pricing, agreed in a written quote.
- Recurring cost: seat charges and any usage beyond plan limits recur monthly, and your warehouse compute for experiment queries is billed by your warehouse provider, not by GrowthBook.
- Cost drivers: the number of people who need access and how many projects you run.
Confirm current seat prices, plan limits and what counts as a user on the pricing page before you budget, because hosted tiers change.
The self-hosted Open Source plan costs no license fee. It is free with unlimited users, 1 project and unlimited API requests, according to GrowthBook's pricing page. You run the bundled Next.js front end, Express API and Python statistics engine yourself, along with the metadata database.
- License fee: none for the Open Source plan.
- Project limit: 1 project, which matters if you plan several product areas or business units.
- User limit: unlimited users, so access cost does not scale with headcount.
- Your costs: hosting, the MongoDB or compatible database, backups, upgrades and the staff who operate them.
- Support: community channels only, unless you buy a support arrangement from a third party.
Ask what your team will spend each year on infrastructure and operations, and confirm that one project is enough for your planned rollout before you commit to this path.
The self-hosted Enterprise edition adds controls that the free Open Source plan does not include. GrowthBook's pricing page lists these as the features to check against your requirements: SSO and SCIM, advanced permissioning, approval workflows, multi-armed bandits, safe rollouts, ramp schedules, sticky bucketing and holdouts.
- Identity: SSO and SCIM for provisioning and deprovisioning users from your identity provider.
- Access control: advanced permissioning and approval workflows for production changes.
- Experiment controls: safe rollouts, ramp schedules, sticky bucketing and holdouts.
- Analysis methods: multi-armed bandits for adaptive allocation.
- Commercial terms: Enterprise pricing is custom and is governed by the GrowthBook Enterprise License.
Before purchase, get the feature list for your exact edition in writing and confirm which items are included at the time of purchase, since packaging can change.
GrowthBook uses a split license. The LICENSE file states that code outside the enterprise directories (packages/back-end/src/enterprise, packages/front-end/enterprise and packages/shared/src/enterprise) is MIT Expat licensed. Those three directories fall under the GrowthBook Enterprise License. You can read the terms directly in the GrowthBook LICENSE file.
- Forks: the MIT part lets you fork and modify the non-enterprise code, subject to the MIT notice requirement.
- Internal changes: you may change MIT code for internal use without publishing it, but you must keep the copyright notice.
- Enterprise directories: changes or use of those directories depend on the Enterprise License terms, so do not assume an internal patch there is free to run.
- Code audits: the MIT code can be reviewed by your security team, but reviewing enterprise code needs a license that allows that use.
- Version pinning: note the release you deploy, such as the current release line, so you can compare later changes.
Have legal counsel confirm how the split applies to any planned modification, and confirm the enterprise terms with GrowthBook before you rely on them.
Event-based pricing versus seat-based pricing: which model suits your team
Statsig bills on analytics events, so your bill tracks how much telemetry your applications send, not how many people log in. GrowthBook sells its hosted tiers per seat, and its self-hosted Open Source plan carries no per-seat charge for unlimited users, with one project. That difference decides which model is cheaper, and it is easy to misjudge if you only compare list prices. Check the current units on the Statsig pricing page and the GrowthBook pricing page before you model anything, because both vendors change their tiers.
Under an event model, the main drivers are event volume from SDK calls and product analytics, the number of environments that send events, and how many experiments run in parallel. Under a seat model, the drivers are how many people need write access, reviewers for approval workflows, and how many projects you need. Under self-hosting, the bill moves to infrastructure: the GrowthBook container, its MongoDB-compatible database, and the warehouse compute that runs experiment queries. Warehouse compute grows with the number of metrics, the size of the tables queried and how often results refresh, so it is not free just because the license is.
The condition that favors an event model is a small, stable group of people managing flags across a high-traffic product, where the team is small and event volume is modest. The condition that favors a seat model is a large group of non-engineers reviewing experiments, where per-seat fees would add up quickly. Ask any vendor for a written quote tied to your event counts, seat roster, project count and the Enterprise features you need, such as SSO, SCIM and approval workflows. Then estimate warehouse query cost with your data team on your own tables, since no vendor figure will reflect your data volume.
How a move from Statsig to GrowthBook proceeds
The sequence moves gates, configs, experiments and segments into a self-hosted GrowthBook instance while keeping Statsig running until each flag and experiment is verified. It ends with a documented cutover and a retired Statsig account.
Inventory every Statsig object and its owner
Export a list of feature gates, dynamic configs, experiments, segments, tags and metrics from the Statsig console, noting which application, team and environment uses each one. Mark which experiments are running, which are concluded and which gates are kept only as permanent kill switches. Your engineering lead and the experiment owners should sign off on the list. The output is a reviewed inventory that becomes the acceptance checklist for the rest of the move.
Stand up self-hosted GrowthBook and connect the warehouse
Deploy GrowthBook in your own infrastructure using the Docker image or the official Helm chart, with a managed MongoDB-compatible database for metadata. Connect the data source that holds your event data, such as Snowflake, BigQuery or another supported warehouse, using read-only credentials that run SELECT queries only. Confirm that a test query returns results and that the instance can reach your SSO provider if you need it. The output is a running instance that can query your warehouse.
Create a read-only Statsig Console API key
Generate a Console API key in Statsig with read-only permissions and store it in your secrets manager, not in a ticket or chat thread. Limit access to the people running the import. Record who created the key and when, so it can be revoked at cutover. The output is a single read-only credential that the GrowthBook Statsig importer can use to fetch environments, tags, segments, feature gates, dynamic configs and experiments.
Run the importer and review the preview
Start the Statsig migration in GrowthBook and let it load objects into a preview before anything is written. Compare the preview with your inventory, object by object. Note which gates, configs and experiments import cleanly and which the importer skips or flags. Advanced setups may include scenarios the importer cannot handle, so expect a list of items for manual rebuild. Metric sources and metrics are in beta and are limited to warehouse-native Statsig metrics, so confirm early whether your metrics qualify. The output is a signed-off list of imported items and a separate list for manual rebuild.
Rebuild manual items and refactor SDK calls
Recreate any objects the importer could not carry over, including metrics that fall outside the beta scope, and check imported targeting rules and rollouts against the original Statsig definitions. Replace Statsig SDK calls in the application with the GrowthBook SDK for each language in use, changing one service at a time. Feature gate checks become flag evaluations, so test that each code path returns the same value as before. The output is a reviewed set of GrowthBook definitions and application code that passes the same test cases as the Statsig version.
Run both systems in parallel and verify results
Keep Statsig active while GrowthBook serves a limited set of flags and experiments, and compare assignments and exposure logs between the two. Check that experiment results computed from your warehouse match the figures you expect from the concluded Statsig experiments. Involve the analysts who read experiment results, since they will need to trust the new numbers. The output is a documented comparison that shows each migrated flag and experiment behaves correctly before you switch traffic over.
Cut over traffic and monitor
Switch each service to GrowthBook in a planned change window, starting with lower-risk flags and ending with active experiments. Watch error rates and flag evaluation outcomes for each service after the change, with a documented rollback path to the Statsig SDK. Record the cutover date for every service in the inventory. The output is a complete change log in which every production service evaluates flags through GrowthBook.
Decommission Statsig and retire the key
Once every service and experiment has moved and the parallel period is closed, revoke the read-only Console API key and remove Statsig SDK dependencies from the codebase. Confirm with your contract owner which data retention and export obligations apply to the Statsig account before you cancel it, and export any records you must keep. The output is a closed inventory, a revoked credential and a written record that the Statsig account has ended.
Questions buyers ask before choosing GrowthBook over Statsig
What does it cost to run a self-hosted GrowthBook deployment?
The GrowthBook software itself carries no license fee on the free self-hosted Open Source plan, so the recurring cost is the infrastructure and the people who run it. The GrowthBook self-hosting documentation bundles the Next.js front end, Express API and Python statistics engine in one Docker image, and stores metadata in MongoDB or a compatible database. The docs suggest a managed service such as MongoDB Atlas or AWS DocumentDB for production, which is a separate line item. Warehouse compute for experiment queries is often the largest variable cost, because GrowthBook runs SELECT queries against your own warehouse. Staff time covers upgrades, backups and on-call support. Ask any quote to break these out separately, and ask which Enterprise features, such as SSO and SCIM, are priced in.
How long does a migration from Statsig to GrowthBook take?
The duration depends mainly on how many objects you move, how many SDK calls you refactor, and how many metrics you rebuild. GrowthBook's Statsig importer retrieves environments, tags, segments, feature gates, dynamic configs and experiments with a Console API key. Metric sources and metrics are in beta and limited to warehouse-native Statsig metrics, so metric rebuilds often take the most planning. The application code must also switch from the Statsig SDK to a GrowthBook SDK, which the importer does not do for you. No duration figure is documented in the sources we reviewed, so ask for a timeline based on your own inventory of gates, experiments and SDK call sites in a written scope.
Can an internal team migrate to GrowthBook without outside help?
Yes, many internal teams can run a migration with their own staff, provided they have the right skills. The work needs engineers who can refactor SDK calls in each service, data engineers or analysts who understand your warehouse schema and metric definitions, and someone who can operate a Docker or Kubernetes deployment with MongoDB. GrowthBook maintains an official Helm chart for Kubernetes, which helps teams that already run clusters. Security or platform staff should own SSO, backups and access control. An outside partner is most useful for scoping, hardening and documenting the deployment, and for running the cutover. Confirm each skill gap against your own team before deciding.
What does the migration need from our side?
The work needs access and decisions from several owners before any technical step starts. Engineering must provide repository access and a list of services that call the Statsig SDK. Data teams must grant GrowthBook read-only credentials to the warehouse, which GrowthBook uses to run SELECT queries and receive only aggregated statistics. Someone with Statsig administration rights must create a read-only Console API key for the importer. Security and identity teams should decide how SSO, SCIM and role-based permissions map to your groups, since these are Enterprise features on the self-hosted plan. Product and compliance owners should approve metric definitions and any approval workflows before the cutover.
Does Statsig's acquisition by Amplitude change the decision to move?
The change in ownership is a reason to review your contract and plan an exit, but it does not decide the question by itself. Statsig announced on September 2, 2025 that it would join OpenAI, and a Statsig blog note states that Amplitude acquired Statsig on May 5, 2026. The sources we reviewed do not document how the product, pricing or data terms will change after the acquisition. Ask Statsig in writing about the roadmap, data residency, pricing changes and support commitments, and check the notice periods in your agreement. If you decide to stay, an exit plan still lowers future risk. Your own contract review should guide the decision.
Is GrowthBook fully open source for self-hosting?
GrowthBook is mostly open source, but not every directory is. According to its LICENSE file, code outside the enterprise directories is MIT Expat licensed, while the packages/back-end/src/enterprise, packages/front-end/enterprise and packages/shared/src/enterprise directories fall under the GrowthBook Enterprise License. Features such as SSO and SCIM, advanced permissioning, approval workflows and holdouts sit in the paid self-hosted Enterprise tier. Your legal team should read the LICENSE file and confirm which features your deployment will use, especially if you plan to modify or redistribute the code.
How does GrowthBook read our experiment data without copying it out?
GrowthBook connects to your own data source and analyzes experiments there, rather than ingesting raw events into its own store. The data source documentation lists support for BigQuery, Snowflake, Redshift, Databricks, ClickHouse, Postgres, MySQL, SQL Server, Athena, Presto or Trino and Vertica. GrowthBook runs only SELECT queries and transmits only aggregated statistics. Your data team should confirm that the connected role has read-only permissions, that the query cost is acceptable for your warehouse plan, and that the metric definitions match your reporting. This design is also why warehouse compute belongs in your cost model.
What to confirm with Statsig, Amplitude and your own team before deciding
Start by putting the questions to the vendor in writing. Statsig's blog states that the company agreed to join OpenAI in September 2025 and that Amplitude acquired Statsig on May 5, 2026, but the post does not tell you how your contract, pricing units or data terms will change. Ask Statsig and Amplitude to confirm, in writing, the product roadmap for the features you use, the support tier and response commitments that will apply after the change, where your event and experiment data is stored and processed, and whether any subprocessor or data location changes are planned. Check your current order form for renewal dates, notice periods, termination rights and any change-of-control clause. Request the answers before you commit budget, so you are not relying on verbal assurances from a sales conversation.
On your side, the first check is warehouse ownership. GrowthBook reads experiment data from your own source with read-only SELECT queries, so you need to confirm which warehouse holds your exposure and metric events, who owns its credentials, and whether the data team agrees to grant a read-only role. Next, compare your feature list with the free self-hosted Open Source plan on the GrowthBook pricing page, which allows one project and unlimited users. If you need SSO, SCIM, approval workflows, holdouts or sticky bucketing, those are listed as self-hosted Enterprise features, so put them on the scope and the quote. Finally, decide whether you need a vendor to answer your support tickets or whether an internal platform team and a fixed-scope implementation partner can cover operations.
How DeployOpen helps you evaluate, implement and migrate
DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a move from Statsig to GrowthBook, we start with a written scope that tests your current gates, experiments and warehouse setup against what GrowthBook can carry over and what it cannot.
How we scope
- We inventory your Statsig gates, dynamic configs, experiments, segments and metrics, and confirm which ones depend on Enterprise-only features.
- We confirm your warehouse (such as Snowflake or BigQuery), read-only access model and the compute your experiment queries will use.
- We agree deliverables, timelines and exclusions in writing before work starts, since engagements are fixed-scope.
How we build
- We deploy GrowthBook from its self-hosting setup, choosing the Docker image or official Helm chart that fits your Kubernetes or VM estate.
- We run the Statsig importer against a read-only Console API key in a test environment and review every imported object before cutover.
- We refactor Statsig SDK calls to GrowthBook SDKs in a staged way and test assignment, exposure logging and metric results against known baselines.
How we hand over
- We document architecture, backup and recovery steps, metadata database operations and warehouse query permissions for your own teams.
- We provide a cutover runbook, rollback plan and a list of items the importer did not carry over, so nothing is lost silently.
- We prepare configuration, access control and evidence records that your compliance assessors or auditors may request. We do not issue audit reports or certifications.
How we support
- Ongoing support, upgrades and continuous security testing are available as a retainer after handover.
- We track GrowthBook releases and license terms, including the split between MIT code and the Enterprise directories, and plan upgrades with you.
- We can review your renewal and contract position on Statsig with you, so the decision to stay or move is based on written terms.
