Can you keep warehouse-native experimentation without the Statsig Enterprise plan?
If your Statsig renewal is pushing you toward Enterprise only to keep experiment data in your warehouse, or a residency rule requires that event data never leave your environment, self-hosted GrowthBook can run warehouse-native analysis against Snowflake, BigQuery, Databricks and other supported sources, sending back only aggregated statistics. The analysis engine runs read-only SELECT queries in your data platform, so the warehouse remains the system of record. The open-source edition of GrowthBook is MIT licensed outside its enterprise directories, so the core warehouse-native capability is not gated behind a commercial tier.
The trade-off is in the operations and the migration. You will run the GrowthBook image, its MongoDB-compatible metadata store, file storage and the warehouse credentials yourself, and you pay for the warehouse compute that experiment queries consume. Metric migration from Statsig is still beta and depends on a connected warehouse, so plan to rebuild or verify metric definitions by hand for anything the importer does not carry over. Confirm the current state of the Statsig importer in the GrowthBook Statsig migration guide before you commit to a timeline, and confirm which warehouse your organization is permitted to grant a read-only role against.
Before you decide, ask your security team to confirm the read-only role scope, the network path from GrowthBook to the warehouse, and where query logs and aggregate results are retained. Check also whether any approval workflow, SSO or permissioning control you rely on at the Statsig Enterprise tier is in the self-hosted Enterprise tier of GrowthBook, which is a separately licensed product under the GrowthBook Enterprise License. Our GrowthBook data source documentation lists the supported sources and is the natural next read for mapping your warehouse to the setup.
Which Statsig warehouse-native capabilities map to GrowthBook
This table compares the warehouse-native capabilities Statsig sells on its Enterprise plan with what GrowthBook provides, both on the free self-hosted Open Source plan and in the self-hosted Enterprise tier. Read each row for the capability, the GrowthBook equivalent and the coverage note, since several items depend on the paid self-hosted tier. Confirm your warehouse is on GrowthBook's supported data source list before you plan the rollout.
| Capability | GrowthBook equivalent | Coverage note |
|---|---|---|
| Warehouse connection and read-only SELECT access | GrowthBook connects to your warehouse and runs only SELECT queries against your own data | Supported sources include BigQuery, Snowflake, Redshift, Databricks and Postgres among others; confirm your warehouse in the data source documentation |
| Aggregate-only data transfer | Only aggregated experiment statistics are sent back to GrowthBook, not raw event rows | Confirm with your security team that aggregates meet your data classification rules before approval |
| Metric and experiment definitions | Metrics and experiments are defined in GrowthBook against tables and columns in your warehouse | Available on the free Open Source plan; metric logic must be maintained by your analytics team |
| Statsig metric import (beta) | GrowthBook's Statsig importer can bring over warehouse-native Statsig metrics in beta | Limited to warehouse-native Statsig metrics and requires a connected warehouse; treat as beta and validate each metric |
| SSO and SCIM | Provided by the self-hosted Enterprise tier | Not included in the Open Source plan; ask GrowthBook for the current self-hosted Enterprise terms |
| Approval workflows and holdouts | Provided by the self-hosted Enterprise tier | Not included in the Open Source plan; plan manual review and holdout tracking if you stay on the free plan |
| SDK switch | Application code moves from Statsig SDK calls to a GrowthBook SDK after import | The importer does not rewrite code; budget developer time for each service that calls the Statsig SDK |
When GrowthBook self-hosted fits warehouse-native needs
Self-hosting GrowthBook moves the experiment analysis layer into your own infrastructure, but the license, plan tier and analytics ownership each decide how much you actually take on. The cards below cover the decisions to make before committing to this path.
Open Source plan versus self-hosted Enterprise
The self-hosted Open Source plan is free with unlimited users, 1 project and unlimited API requests. Warehouse-native analysis is available in that plan, but SSO and SCIM, advanced permissioning, approval workflows, safe rollouts, holdouts and sticky bucketing are Enterprise features. Check which of these your governance model requires, because Statsig's warehouse native capability sits in its Enterprise plan and you should compare like with like.
MIT outside enterprise directories
GrowthBook's LICENSE file places code outside its enterprise directories under the MIT Expat license. Legal teams should confirm that the directories they deploy match the license they approved, since the back end, front end and shared packages each contain a separate enterprise folder. Record the exact release you deploy, because licensing terms can change between versions.
GrowthBook Enterprise License for enterprise code
Code inside the enterprise directories falls under the GrowthBook Enterprise License, not MIT. If you buy an Enterprise subscription, the license terms that govern those directories apply to your use, support and redistribution. Ask GrowthBook to confirm in writing which terms cover your self-hosted deployment, including any restrictions on modifying or hosting enterprise modules for internal users.
Building queries in-house with BI tools
An alternative is to write experiment SQL yourself and run it in an existing BI or analytics tool. This avoids a new platform but moves statistical methods, metric definitions, variance reduction and result review into your team's own code. It suits teams with a small number of experiments and strong analytics engineering. Expect ongoing maintenance of queries and statistics as metrics change, and confirm who reviews those calculations.
Unleash and Flagsmith do not analyze experiments
Unleash and Flagsmith are feature flag tools that control rollouts and targeting, but they do not replace the experiment analysis layer on their own. If you use Statsig experiments, you need a separate system that computes results from your warehouse data. Plan for either GrowthBook for both jobs or a flag tool paired with GrowthBook or an in-house analysis process, and map which tool owns each metric.
How GrowthBook reads your warehouse without copying events
GrowthBook analyzes experiments where the data already lives. It connects to your data source, such as Snowflake, BigQuery or Databricks, runs only SELECT queries, and receives back aggregated statistics rather than raw event rows. The statistics engine, the Next.js front end and the Express API ship together in a single Docker image, and the application's own metadata (experiments, feature definitions, users and settings) is stored in MongoDB or a compatible database. The GrowthBook data source documentation lists the supported sources, so confirm your warehouse is on that list before you design around it.
Provision three things before the first experiment runs. First, a dedicated read-only role in the warehouse, limited to the schemas that hold exposure and metric tables, with no write or DDL privileges and no access to unrelated datasets. Second, network paths from the GrowthBook API and statistics services to the warehouse endpoint, ideally over private connectivity, with the allowlist owned by your network team. Third, a decision on where assignment and exposure events are logged: GrowthBook expects an exposure table your SDKs or pipeline write to, so the team that owns the event pipeline must agree on the schema, retention and the table name before analysis starts. Confirm these details against the self-hosting and data source documentation for your GrowthBook version.
Keeping raw events in the warehouse does not remove the need to govern access. The read-only role, its credential and the connection string become high-value secrets that GrowthBook must store, so they belong in your secrets manager with rotation and access logging, and the MongoDB metadata store should be treated as sensitive because it holds experiment configuration and user records. Review who can create data sources in the GrowthBook interface, since a new connection can point queries at tables the original design never intended to expose. Log query activity in the warehouse itself, so you can show auditors which queries ran and under which identity.
Migrating Statsig warehouse-native metrics into GrowthBook
This sequence moves your Statsig experiments and warehouse-native metric definitions into GrowthBook while keeping every query inside your own warehouse. It ends with GrowthBook producing results you have checked against known outcomes and application code that has cut over from Statsig SDK calls.
Inventory Statsig metrics and warehouse dependencies
Someone who owns experimentation, with help from a data engineer, lists every Statsig experiment, metric and metric source that runs against your warehouse. Mark which metrics are warehouse-native and which depend on Statsig-hosted event data, because only the warehouse-native ones are covered by the importer's beta metric support. Record the warehouse, schema, tables and the owner of each metric. The step is done when you have a signed-off inventory that separates metrics you can recreate from those that need a different approach.
Connect GrowthBook to the warehouse read-only
A data engineer creates a dedicated warehouse role for GrowthBook that can run SELECT queries on the schemas holding experiment exposure and metric event data, and nothing else. GrowthBook's documentation confirms it runs only SELECT queries and sends back only aggregated statistics, so grant no write or DDL permissions. Add the data source in GrowthBook's data source settings using that role. The step is done when the connection test succeeds and the role's grants have been reviewed by whoever owns warehouse access.
Recreate metric definitions in GrowthBook
An analyst rebuilds each inventoried metric in GrowthBook using the same event names, value columns, filters and denominators that Statsig used, and records the owner and intended use of each one. Keep definitions in version control or a change log so later edits are traceable. Where a Statsig definition relies on logic that does not map cleanly, write the difference down rather than guessing. The step is done when every metric in scope has a documented GrowthBook definition approved by its owner.
Validate results against a known experiment
Pick one completed Statsig experiment whose outcome your team already understands and run the same population, dates and metrics in GrowthBook. Compare exposure counts, sample sizes and the direction and size of each effect with the figures from Statsig's own results and the warehouse. Investigate any gap in assignment, filters or metric logic before trusting new results. The step is done when the comparison is written up, the team accepts the differences, and the metric definitions have been adjusted where needed.
Run the Statsig importer with a Console API key
An administrator creates a read-only Statsig Console API key and runs GrowthBook's Statsig importer, which retrieves environments, tags, segments, feature gates, dynamic configs and experiments. The importer's metric sources and metrics support is in beta and is limited to warehouse-native Statsig metrics, so expect it to bring over only part of the metric set. Keep the key in a secrets manager and revoke it after the import. The step is done when the import completes and the imported objects are listed in GrowthBook for review.
Review beta metric import output manually
An analyst checks each metric the beta importer produced against the inventory and the definitions recreated in GrowthBook. Confirm that the source, filters, aggregation and denominators match, and remove or rebuild anything that imported incorrectly. Record which items were imported automatically and which were rebuilt by hand, since the importer's output is a starting point rather than a verified result. The step is done when every experiment in scope has metrics that were checked by a person and the review record is stored with the migration documentation.
Switch application code to GrowthBook SDK calls
Developers replace Statsig SDK calls for gates, dynamic configs and experiments with GrowthBook SDK calls, and check that each feature key, default value and targeting attribute still resolves the same way. GrowthBook's documentation notes that the application must move from the vendor SDK to a GrowthBook SDK after import, and the importer does not do this for you. Test each change in staging before merging. The step is done when the code paths pass tests and no remaining Statsig SDK calls exist in the repositories in scope.
Run both systems in parallel before cutover
Run Statsig and GrowthBook side by side for a period agreed by the experimentation and data owners, comparing assignments, flag evaluations and metric results on live traffic. Investigate every mismatch and fix the cause in GrowthBook or in the application. Set the cutover date only after the owners sign off on parity, and keep the Statsig contract and export in place until then. The step is done when the parity report shows no unexplained differences and the owners approve switching off Statsig.
Where metric definitions and beta import need manual checks
The Statsig importer's metric support is still beta, and GrowthBook's Statsig migration guide limits metric sources and metrics to warehouse-native Statsig metrics. Two consequences follow. First, you need a connected warehouse before any metric can come across, so confirm that the warehouse connection exists and is tested before you plan the import window. Second, a metric that Statsig computed in its own hosted pipeline has no warehouse-native equivalent to import, so it will need to be rebuilt by hand or dropped. Build an inventory of every metric used in an active decision, then sort it into three groups: imported, rebuilt and retired.
Imported metrics are not automatically equivalent. For each one, compare the metric SQL, the event and user filters, the denominator, the attribution window and the handling of late or duplicate events with the original Statsig definition. Run both definitions against the same date range in the warehouse and record where the numbers diverge. Treat any difference in denominators or attribution windows as a blocker for that experiment until someone who owns the metric signs off. The importer does not guarantee equivalence, so the comparison is your responsibility and should be recorded as part of the change file.
The LaunchDarkly importer documentation warns that advanced setups may include scenarios the tool cannot handle, and GrowthBook's own guidance says the application still has to switch from the LaunchDarkly SDK to a GrowthBook SDK after import. Expect similar gaps on the Statsig side. Ask the vendor or the GrowthBook community which Statsig configurations are known to fall outside the importer, and check your own estate for custom gate logic, nested segments and experiments that depend on Statsig-specific evaluation. Plan a parallel run for at least one full experiment cycle where both systems evaluate and report, and make cutover conditional on those comparisons.
Questions teams ask before replacing Statsig warehouse native
Can our team run GrowthBook against our warehouse without outside help?
Yes, many teams can, but the work spans three skill sets: running a containerized app with MongoDB, connecting a read-only warehouse account, and defining metrics that match how your experiments are analyzed today. GrowthBook bundles its front end, Express API and Python statistics engine in a single Docker image, and it maintains an official Helm chart for Kubernetes. The harder part is usually metric definition and sign-off with analysts. An outside team can take that on under a fixed-scope written agreement, while your staff keeps ownership of the warehouse and the experiments.
What drives the effort of a Statsig warehouse native replacement?
Effort rises with the number of metrics, the number of warehouses and data sources, and the identity and approval rules you need. Each metric needs a clear definition, a source table and an owner, so a large metric catalog takes longer than a small one. Each connected warehouse needs its own read-only account and testing. On the self-hosted Enterprise tier, SSO and SCIM, advanced permissioning and approval workflows are listed as Enterprise features on the GrowthBook pricing page, so organizations that need them should scope them early. Ask for the work to be broken into those components in any written scope.
What costs recur after the migration is finished?
Recurring costs are the hosting for the GrowthBook container, the MongoDB or compatible database, file storage if you use Amazon S3 or Google Cloud Storage, and warehouse compute for experiment queries, which runs on your own warehouse bill. Upgrades also recur: GrowthBook v5.1.0 was released on September 22, 2026, according to the GrowthBook GitHub releases page, so you should plan a regular review of each release. If you buy Enterprise, the seat or contract fees recur as well. Ask for a quote that separates one-time setup from these monthly and annual components.
What does the work need from our people?
Three groups usually need to be involved. Warehouse administrators create the read-only account and confirm that SELECT-only access is enforced. Identity team members handle SSO, SCIM and role mapping if you use them. Experiment owners confirm metric definitions, attribution windows and the decision rules they rely on. GrowthBook only transmits aggregated statistics, but your warehouse team still controls which tables it can read. Plan time for these people before the project starts, because delays in access approvals are a common reason plans slip.
Does the Statsig importer move everything, including metrics?
No. 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 are limited to warehouse-native Statsig metrics, so metrics that were not defined on a warehouse source need to be rebuilt by hand. Your team also has to change the Statsig SDK calls in the application to a GrowthBook SDK. Confirm the beta metric coverage against your own metric list before you commit to a timeline, and see the GrowthBook migration guide for the current import scope.
How do we confirm GrowthBook supports our warehouse?
Check the data source list in the GrowthBook documentation against your warehouse product and version. The documented list includes BigQuery, Snowflake, Redshift, Databricks, ClickHouse, Postgres, MySQL, SQL Server, Athena, Presto or Trino and Vertica. If your warehouse is not on that list, ask GrowthBook directly whether a route exists before you plan around it. Then run a proof of concept that connects a read-only account and executes one representative experiment query, so you can confirm the results match your current analysis.
Will self-hosting GrowthBook change how our experiment data is handled?
Yes, in a useful way. GrowthBook runs read-only SELECT queries against your own data source and transmits only aggregated statistics, so raw event data stays in the warehouse you already govern. That said, you become responsible for the GrowthBook deployment, its database, its access controls and its logs. Any compliance evidence for those controls has to come from your own environment and an independent assessor, since DeployOpen prepares systems and evidence but does not issue audit reports or certifications.
Running GrowthBook beside an existing warehouse and analytics stack
GrowthBook sends queries to your warehouse and returns only aggregates, so the warehouse stays the system of record. The cards below cover the access model, the BI overlap, the parallel run with Statsig and where product analytics should sit.
Warehouse as system of record
GrowthBook reads event and metric tables through SELECT queries and keeps only experiment results and metadata in its own database. The raw events, exposure logs and metric tables therefore stay in the warehouse, where your existing retention and access controls apply. Confirm which exposure table your Statsig events currently land in, because GrowthBook needs a table that records which variant each user saw.
Dedicated read-only warehouse role
Create a service role for GrowthBook that can select only from the schemas that hold experiment exposure and metric tables. Do not reuse the credentials of a BI tool or a data engineer, because those accounts usually have wider grants. Ask your warehouse team to confirm that the role cannot write, create or drop objects, and record the role in your access review.
Shared roles with existing BI tools
Dashboards in Tableau, Looker or Power BI may already query the same metric tables, so metric definitions can drift between tools. Agree one owner for each metric definition and decide whether GrowthBook or the BI layer is the reference. Check that BI users keep their own grants and that query load from experiments does not slow reports used by finance or operations.
Warehouse compute for experiment queries
Each analysis runs queries against your warehouse, so compute is billed by your warehouse provider and grows with the number of metrics, experiments and refresh schedules. Ask your data platform team to estimate query cost for a typical month of experiments before turning on scheduled refreshes. Set refresh frequency per experiment rather than running every analysis continuously.
Parallel run with Statsig
Keep Statsig gates and experiments live while GrowthBook analyzes the same metrics in a validation period. Compare exposure counts and metric results for a few experiments before you cut over assignment, since a mismatch usually points to different hashing or exposure definitions. Do not stop Statsig logging until your contract and data export plan confirm what happens to historical results.
Separate analytics tool for product analytics
If product funnels, retention and dashboards live in Statsig today, GrowthBook covers experiments but not general product analytics. Decide whether analytics moves to a separate self-hosted tool, such as PostHog, or stays on a warehouse-based BI layer. Check that each event has one owner and one schema, so that experiment metrics and product dashboards do not disagree.
What you pay for when you run GrowthBook yourself
Running GrowthBook yourself has no license fee for the core product, but it is not zero cost. The free self-hosted Open Source plan allows 1 project with unlimited users and unlimited API requests, according to the GrowthBook pricing page. Paid self-hosted Enterprise seats add SSO and SCIM, advanced permissioning, approval workflows, safe rollouts, holdouts and other features that the free plan does not include. Whether you need those features is the first cost decision, and the price of the Enterprise tier must come from a written quote, not from this page. Ask the vendor for the per-seat basis, minimum seat counts and whether the quote covers self-hosted use specifically.
The recurring costs sit in the infrastructure around the application. GrowthBook bundles its front end, API and statistics engine in one Docker image, but it stores metadata in MongoDB or a compatible database, and the docs suggest a managed service such as MongoDB Atlas or AWS DocumentDB for production. That database, the compute that runs the container or Helm chart, and object storage for uploads (local, Amazon S3 or Google Cloud Storage) each carry their own bill. The largest variable cost is usually warehouse compute: every experiment analysis runs SELECT queries in your Snowflake, BigQuery or Databricks account, so query volume, metric count and refresh frequency drive that bill. Ask your warehouse team to model it on a sample of real experiments before you commit.
The one-time costs are the migration and the metric rebuild. Engineers must replace Statsig SDK calls with GrowthBook SDK calls, because the importers do not change application code, and the LaunchDarkly importer documentation says so directly. Metric definitions often need rebuilding against your own tables, and the Statsig metric import is in beta and limited to warehouse-native Statsig metrics, so plan for manual work. Recurring staff costs are the people who apply upgrades (the project released v5.1.0 on September 22, 2026), maintain backups of the metadata database, rotate credentials and handle incidents. Confirm internally who owns that rota before you switch off Statsig.
How DeployOpen scopes and delivers a GrowthBook warehouse-native setup
A fixed scope, agreed in writing, moves your experiment analysis onto GrowthBook against your own warehouse, with read-only access, rebuilt metrics, validated results and a hardened, backed-up deployment. Each step ends with a check you can review.
Agree the scope and warehouse inventory in writing
DeployOpen reviews your Statsig contract, the warehouses and tables that hold exposure and event data, the number of experiments in flight, and the SDKs in your applications. The output is a written scope with deliverables, responsibilities and acceptance checks, agreed before any work starts. Quotes follow from this scope, and DeployOpen does not publish a price list. You confirm the scope in writing before the engagement begins.
Deploy GrowthBook in your own infrastructure
DeployOpen installs GrowthBook in your cloud account, data center or air-gapped network, using the single Docker image or the official Helm chart for Kubernetes. The team sets up MongoDB or a compatible database, preferably a managed service for production, and file storage on local disk, Amazon S3 or Google Cloud Storage as your design requires. The check is a running instance that you can reach only through the access paths you approved, with the version recorded. Confirm the current release notes before you pin a version.
Design the read-only warehouse role
DeployOpen creates a dedicated warehouse role that can run SELECT queries against only the datasets used for experiments, and nothing else. GrowthBook transmits aggregated statistics back, so the role should not need write or broad read rights. Your data platform team reviews the grants, network path and credential storage. The output is a documented role definition and a connection test that succeeds for the approved datasets and fails for anything outside them.
Rebuild and validate metric definitions
DeployOpen rebuilds your key metrics as GrowthBook metric definitions, mapping each one to the events, identifiers and filters your warehouse uses. Statsig's warehouse native metric objects may not carry over automatically, so the team rebuilds them from your documented definitions. Analysts then compare results for a set of completed experiments against numbers your team already trusts. The check is a signed-off list of metrics with reconciled results, and any differences explained before go-live.
Run the Statsig importer and review its gaps
DeployOpen runs GrowthBook's Statsig importer with a read-only Console API key to bring over environments, tags, segments, feature gates, dynamic configs and experiments. Metric sources and metrics are in beta and limited to warehouse-native Statsig metrics, so the team checks which of these carry over and rebuilds the rest in step 4. The output is an import log and a gap list that you review item by item. Expect to verify imported targeting rules and rollouts manually.
Plan the SDK refactoring
DeployOpen maps each Statsig SDK call in your applications to the equivalent GrowthBook SDK call and sequences the change by service. The importer does not switch your application code, so this plan is required. The team documents fallback behavior, sticky bucketing choices and any experiments that cannot be migrated in parallel. The check is a reviewed change list per service and a test plan that confirms the same assignments are made during a controlled cutover.
Harden and back up the GrowthBook services
DeployOpen applies your hardening baseline to the GrowthBook front end, API, statistics engine and database, covering access control, secrets handling, network restrictions and logging. It configures scheduled backups of the metadata database and file storage, and tests a restore into a separate environment. Self-hosted Enterprise features such as SSO, SCIM and approval workflows are assessed separately, because the free Open Source plan does not include them. The check is a documented restore test and a hardening record that your security team accepts.
Hand over and offer optional retainers
DeployOpen delivers runbooks, architecture documentation and the evidence your compliance team needs to assess the setup. Your team runs a final review of the metrics, access records and backup results. Ongoing upgrades, support and continuous security testing are available as retainers agreed separately from the implementation scope. The output is an accepted handover package, and the engagement closes only when you sign off the acceptance checks in the written scope.
