Why warehouse-native experimentation changes the open source setup
If your digital team already runs an event warehouse and wants A/B test analysis without copying user-level data into a SaaS experimentation tool, warehouse-native experimentation is the pattern to plan around. With GrowthBook, the statistics run against your own BigQuery, Snowflake, ClickHouse or Postgres data, and only aggregated results come back to the experiment dashboard. The warehouse, the metric definitions and the location of your data drive the build far more than the experiment interface does, so the first design work is about tables, identifiers and ownership of metrics, not about screens.
GrowthBook is the platform this page is built around. Its self-hosted Open Source edition is free, with unlimited users and one project, and it covers the core of a warehouse-native setup. The documented gaps matter here: the self-hosted Enterprise tier adds SSO and SCIM, advanced permissioning, approval workflows, safe rollouts, holdouts and sticky bucketing, among other features. Before you commit, confirm against the current GrowthBook pricing page which of these your governance model needs, because approval trails and role separation are often what regulated teams require first, not the statistics themselves.
The hosting model is the second decision. GrowthBook ships its front end, API and statistics engine as one Docker image and keeps experiment metadata in MongoDB or a compatible database, so the application stores configuration and results while the raw events stay in your warehouse. Your team should confirm the read-only credentials, the SELECT-only query behavior and which network paths the GrowthBook service needs to reach the warehouse. These checks, along with a named owner for each metric definition, determine whether the setup holds up after the first experiment.
What the warehouse, licensing and data location require
This table compares each requirement that shapes a warehouse-native GrowthBook build, from the warehouse connection and SQL metric definitions to licensing and identity. Read each row as a build decision: what it asks your team to do, and what to confirm with GrowthBook and your warehouse vendor before you commit.
| Requirement | What it means for the build | What to confirm |
|---|---|---|
| Warehouse connection | GrowthBook queries your existing BigQuery, Snowflake, ClickHouse, Postgres or other supported source. Plan one dedicated read identity per source rather than reusing an administrator account. | Confirm the exact connector and version for your warehouse with GrowthBook's data source documentation and your warehouse vendor. |
| Read-only SELECT access | GrowthBook runs only SELECT queries, so the service account needs read grants on the event, assignment and order tables used by experiments, and no write or DDL rights. | Ask GrowthBook to document the query patterns it runs, then have your DBA verify grants and audit the account's query log. |
| Metric definitions in SQL | Analytics owns metric SQL such as conversion, revenue per visitor or refund rate. Store definitions in version control and review them like code, because a wrong join changes the decision. | Confirm which tables and identifiers each metric depends on, and who approves changes before they reach production experiments. |
| Aggregates-only egress | Only aggregated statistics leave the warehouse for the analysis service, so row-level customer data stays in your environment. Validate this against your own network logs and the data flow diagram before sign-off. | Ask GrowthBook for the exact fields returned to the application and whether any row-level sample is ever stored in metadata. |
| Data location and transfer documentation | Where the warehouse, the GrowthBook application and its metadata database run determines residency. If the stack is in one region, keep the region fixed in the design record and in transfer assessments. | Confirm the hosting region of each component and whether any telemetry or support access leaves that region, with your legal team. |
| Enterprise directories versus MIT code | GrowthBook's LICENSE file says code outside its enterprise directories is MIT Expat licensed, while the enterprise directories fall under the GrowthBook Enterprise License. Your build must record which features come from which directory before you enable them. | Have counsel review the LICENSE file for the version you deploy, and confirm which features you need, such as SSO, SCIM, approvals or holdouts, sit in the Enterprise License scope. |
| Identity controls on metric changes | Who can edit metrics, create experiments or change analysis settings should map to named roles. Without Enterprise permissioning and approval workflows, you need a separate change process for metric SQL. | Confirm with GrowthBook which permission and approval features each self-hosted edition provides, and how logs of metric edits are retained. |
| Warehouse and database operations | The warehouse's own backup, access logging and upgrade process still applies to the tables experiments query. Confirm that your warehouse vendor's logging covers the service account and that restore tests include the experiment tables. | Ask your warehouse vendor for its backup, audit log and upgrade documentation, and confirm the supported version with your platform team. |
What leaves the warehouse and what stays inside it
GrowthBook analyzes experiments in place and sends only aggregated statistics back, so user-level rows stay in your warehouse. According to the GrowthBook data source documentation, the platform runs only SELECT queries against BigQuery, Snowflake, ClickHouse, Postgres or the other supported sources, and it transmits only aggregated statistics. That makes the warehouse the place where raw event and assignment tables are read, not copied. Confirm the exact query grants you issue to the GrowthBook service account, because a read role that can see personal identifiers in source tables still exposes them to the query layer even though they never leave.
Several flows still move outside the warehouse, and each one needs a line in your data flow record. Experiment configuration, feature definitions and results are written to the GrowthBook application. Its metadata lives in MongoDB or a compatible database, which the self-hosting documentation suggests running as a managed service in production. The SDKs in your applications call GrowthBook to receive assignments, and those calls carry the attributes you pass for targeting. Telemetry from the application, the browser or the SDK may also leave your network. Ask your GrowthBook partner to list every outbound call, including any update checks, and confirm which of them your privacy notice and transfer documentation must cover.
Before you approve the design, map each flow in your own environment: source table, query, result set, destination, retention and owner. Treat the metadata database as a separate system with its own location decision. It sits outside the warehouse, so it may fall under different residency, backup and access rules than the data you analyze, and it stores experiment names, metric definitions and results that can still be sensitive. Decide where it runs, who administers it and how it is backed up before the first experiment launches, and test a restore of that store, not only of the warehouse.
Which warehouse and deployment fits which team
Most teams will not choose a warehouse for experimentation alone, so the question is which store already holds the revenue and event data and which GrowthBook edition the governance requirements justify. The cards below cover the warehouses teams commonly run and the self-hosted GrowthBook editions, with the checks to make before committing.
BigQuery as the analysis warehouse
BigQuery is a common home for event and order data in Google Cloud estates, and GrowthBook connects to it as a data source. The key check is where the dataset physically lives and who holds the service account GrowthBook uses, since that account needs read access to the tables behind each metric. Confirm the data residency of the dataset, the query cost model your finance team accepts for frequent experiment queries, and whether analysts already maintain SQL models you can reuse for metric definitions.
Snowflake as the governed warehouse
Snowflake suits organizations where a central data team already governs shared datasets and role-based access. GrowthBook runs only SELECT queries and returns aggregated statistics, which fits a read-only role scoped to the experiment and revenue schemas. Confirm that the warehouse role can be limited to those schemas, that query credits for scheduled experiment refreshes are budgeted, and who approves changes to metric SQL.
ClickHouse for high-volume events
ClickHouse is open source under the Apache License 2.0, so the server can run on your own hosts with no license fee, while ClickHouse Inc. sells ClickHouse Cloud as a separate managed service. Teams with very high event volumes often choose it for fast aggregate queries. Plan for replication with ClickHouse Keeper, backups with restore tests, and an upgrade path, because the security policy lists only a few supported versions at any time.
PostgreSQL for smaller event volumes
PostgreSQL is released under the PostgreSQL License, and it is often the lowest-friction choice for product teams that already run it for application data. Confirm that the version you run is still supported, since the versioning policy sets an end date for each major release, and that read replicas and failover tooling match your availability needs. Analytical queries on large event tables can load the primary, so a separate replica or analytics copy is worth confirming early.
GrowthBook self-hosted Open Source
The self-hosted Open Source plan is free and includes unlimited users, one project and unlimited API requests, which suits a single product team testing with warehouse-native analysis. It does not include SSO and SCIM, approval workflows, holdouts or safe rollouts. The main running costs are the hosts for the Docker or Helm deployment, a managed MongoDB-compatible metadata database, and the staff time to upgrade, back up and monitor it. Confirm that one project meets your structure before you start.
GrowthBook self-hosted Enterprise
Self-hosted Enterprise adds SSO and SCIM, advanced permissioning, approval workflows, multi-armed bandits, safe rollouts, ramp schedules, sticky bucketing and holdouts. These features matter when several teams share the platform or when experiment launches need recorded approval. Enterprise is priced by custom quote, so ask the vendor for a written price and confirm which Enterprise features you need before buying the edition. Your implementation partner can scope the identity and approval integration as a separate line item.
How the rollout moves from data model to first trusted result
The sequence turns raw warehouse tables into a set of exposure and metric definitions that analysts have reviewed and a pilot experiment has reproduced against known results, before anyone outside the data team relies on a readout. Each phase ends with a named artifact that the next phase depends on.
Inventory data sources and map identities
The data engineering lead and an analyst list the tables that will hold assignment logs, page or product events, orders and customer records, then document which identifier links an anonymous visitor to a logged-in user and to an order. This includes checking how often identifiers change, such as after login or a device switch. The step closes with a data inventory and identity map signed off by the data owner and the privacy lead, which shows every join the experiment analysis will depend on.
Model exposure and metric events in the warehouse
Data engineers build a validated exposure table that records which unit saw which variant and when, derived from the experimentation SDK or the flag service's assignment events. Event tables for the conversion and guardrail metrics are then built or confirmed, with timestamps and units defined the same way across sources. Done means the exposure table reconciles with the flag service's assignment counts for a sample period and the team can explain any gaps, such as bots or duplicate events.
Connect with a read-only account and scoped permissions
The platform team creates a dedicated warehouse role for GrowthBook that can only read the exposure, event and metric schemas it needs, and confirms the connection runs SELECT queries only. GrowthBook's data source documentation states that it sends only aggregated statistics back, so the team should verify this with a test query log. The output is a documented connection with a named owner, a credential rotation plan and a reviewed role grant list.
Define metrics in SQL and get analyst review
Analysts write each metric as SQL against the modeled tables, covering the numerator, denominator, attribution window, exclusions and handling of duplicate or late events. A second analyst reviews each definition and checks it against the business's own reporting figures for a historical period. The deliverable is a signed-off metric catalog with an owner, version and description for every metric, so that a change to a definition is visible and traceable.
Validate a pilot experiment against known results
The team reruns a past or controlled experiment whose outcome is already known, such as a change that is documented to have moved a metric, and compares the platform's sample sizes, conversion rates and confidence intervals with the figures from the original analysis. Differences are traced to exposure logic, metric SQL or the statistics settings and corrected before the next step. Done means the pilot reproduces the known result within a tolerance the analytics lead has agreed in writing and the discrepancy log is closed.
Set access, approval and audit controls before wider use
Before other teams can create experiments, the platform owner assigns project-level roles, decides who can approve results and metric changes, and confirms which audit events are retained and where. Editions differ on approval workflows and advanced permissioning, so this step includes checking the edition in use against the required controls. The output is an access matrix, an approval procedure and a tested audit log export, which the governance owner accepts before rollout.
The data engineering work needed before the first experiment
Before GrowthBook can return a result anyone should trust, the warehouse must already hold four things: stable experiment exposure logs, a consistent user identifier across web and server events, timestamps that support defined analysis windows, and tested metric tables for revenue or conversion. GrowthBook reads these tables and runs its statistics on them, but it does not create them. This work is owned by data engineering and the analytics team, not by the experimentation tool, and it is usually the largest variable in the project because it depends on how far your event pipeline already matches these requirements.
The exposure log is the first thing to check. It records which user or account saw which variant and when, and every metric is joined against it. If the same person can appear under two identifiers (an anonymous browser ID on the website and a customer ID in the order database), users get counted twice or fall out of the analysis entirely. Ask the data team to confirm which identifier the experiment will use, how web and server events are linked to it, and how often exposures are dropped or duplicated. Then ask for a data-quality check on exposure events before any experiment goes live: sample-ratio checks between variants, a count of exposures without a matching user, and a comparison of exposure volume against the page or service logs that produced them. Confirm the exact checks with your analytics engineers, since the right thresholds depend on your traffic and tracking setup.
Metric tables come last and take the longest. Revenue and conversion metrics need agreed definitions for what counts as an order, a refund, a duplicate event and a test account, and those definitions must be tested against finance figures before anyone reads a lift from them. Timestamps need to be in one timezone and one event-time convention so analysis windows can be set without manual correction. Your data engineers should document the transformation models behind each metric table and version them, so a change to a definition shows up in the experiment history instead of silently shifting results. Agree on these owners and this sign-off before the first experiment is scheduled, not after the first result is questioned.
Integration points and deployment pattern
GrowthBook ships as a small set of components that each sit in a different place on your network. Deciding where the application, metadata store, file storage and warehouse connections live determines who can reach what and who carries the operating load.
Single Docker image
GrowthBook bundles its Next.js front end, Express API and Python statistics engine in one Docker image. The application tier is therefore one deployable unit: one image to pin, scan, patch and roll back. Place it inside your private network behind your identity-aware proxy, not on a public address, because the dashboard and API both hold experiment definitions and metric SQL. Confirm which image tag you pin and how your team tests upgrades before rollout.
Helm chart for Kubernetes
GrowthBook maintains an official Helm chart for Kubernetes. If your platform team already runs clusters, the chart fixes the deployment shape in version-controlled values files, which helps when auditors ask how the analysis service was configured. Decide whether the statistics workload shares a node pool with other services, since it runs queries and computation on your behalf. Ask your partner how chart upgrades are tested against your pinned image.
Metadata store and managed options
Experiment definitions, metrics and users are stored in MongoDB or a compatible database. The GrowthBook docs suggest a managed service such as MongoDB Atlas or AWS DocumentDB for production. Choosing managed storage moves backups, patching and failover to the provider, but it also means the metadata leaves your servers, so confirm the region, encryption keys and provider agreement with your data protection team before you sign.
File uploads and storage backends
Uploaded files can be kept on local disk, Amazon S3 or Google Cloud Storage. Local storage is simplest for a single-host install but ties recovery to that host's disk. Object storage is easier to back up and to place in the same region as your warehouse. Confirm that the bucket is private, versioned and included in your backup scope, and that access uses an instance role rather than long-lived keys.
Warehouse credentials and read-only access
Each data source needs a connection that GrowthBook uses to run SELECT queries and receive only aggregated statistics. Create a dedicated service account per warehouse with read access limited to the experiment schemas, and store its secret in your vault, not in environment files checked into source control. Rotate it on your normal schedule. Ask who owns that account, since its query activity appears in your warehouse audit logs.
PgBouncer for Postgres sources
If Postgres is the analysis source, PgBouncer is a lightweight connection pooler you can place between GrowthBook and the database. Experiment analysis can open many short queries, and a pooler limits how many server connections that consumes. Run it close to the database, set pool sizes with the database owner, and confirm that your analysts' reporting load does not share the same pool. This is a planning item for your DBA team, not a default part of the install.
Evidence an auditor or data governance reviewer will ask for
This table maps each piece of evidence a data governance reviewer or auditor is likely to request to the component that produces it in a warehouse-native GrowthBook setup. Read it as a checklist to agree with the data owner before the first experiment runs, since some items depend on the self-hosted Enterprise edition. DeployOpen prepares this evidence for assessments but does not issue audit reports or attestations, which come from independent auditors.
| Evidence item | Component that produces it | What the reviewer checks |
|---|---|---|
| Data flow diagram showing aggregates-only egress | GrowthBook data source documentation and the team's own network design | Confirm that only SELECT queries run in the warehouse and only aggregated statistics leave it, and that no row-level exports are configured |
| Read-only warehouse role configuration | Warehouse access grants (BigQuery, Snowflake, ClickHouse or Postgres roles) | The GrowthBook connection uses a dedicated role limited to read access on the approved schemas, with grants exported and reviewed |
| Metric definitions under version control | Metric SQL stored in the team's Git repository and GrowthBook metric definitions | Each metric has an owner, a reviewed SQL definition, and a history showing who changed it and when |
| Experiment and approval logs | GrowthBook Enterprise audit and approval workflow features (confirm the edition in the written scope) | Who created, started, stopped or shipped each experiment, and whether a second person approved the change |
| Access reviews for metric and experiment changes | GrowthBook user and permission records, plus the identity provider's group membership reports | Periodic confirmation that only current staff hold editor or admin rights over metrics and experiments |
| Backup and restore test records for the warehouse | Warehouse backup tooling, for example ClickHouse BACKUP and RESTORE on a spare cluster, or the Postgres backup and point-in-time recovery setup | Dated restore tests on a non-production cluster, since the ClickHouse backup documentation warns that untested backups often fail to restore |
| Backup and restore test records for the metadata store | MongoDB or compatible database backup jobs for GrowthBook metadata | Restore tests showing experiment definitions, users and settings can be recovered to a working state |
| Upgrade records | Change tickets, release notes and staging test results for GrowthBook, the warehouse engine and the metadata store | Each upgrade was tested in a pre-production environment with representative data before production, and the changelog was reviewed |
Operating the warehouse side without losing results
If your experiment data lives in ClickHouse, your platform team owns the cluster that GrowthBook queries. ClickHouse ships stable releases roughly monthly and LTS releases twice a year, and only some lines receive security updates. Choose a release line deliberately, then keep it within the supported set. The points to confirm with your team and vendor are:
- Release line: Stable releases suit most production use, while LTS releases suit teams that want fewer upgrades. Confirm which line you run. The security policy currently lists 26.9, 26.8, 26.7 and 26.3 as supported, and all other versions as unsupported.
- Keeper quorum: Replication uses ClickHouse Keeper, which the replication guide recommends running on at least three nodes on dedicated hosts in production.
- Restore tests: Backups made with BACKUP and RESTORE protect against loss, but replication does not protect against human error or corruption. The backup documentation warns that an untested backup will probably not restore, so schedule restores on a spare cluster.
- Pre-production upgrades: Read the changelog before each upgrade, since minor backward-incompatible changes can occur, and test with representative data and queries.
- Authentication: Confirm how GrowthBook's query user authenticates, and restrict it to SELECT access on the experiment tables.
Before go-live, confirm the release line, the Keeper topology and the date of your last successful restore test.
PostgreSQL commonly holds GrowthBook's metadata or a smaller warehouse database, so its availability and upgrade path matter to every experiment that depends on it. Plan for minor updates, major upgrades and failover as separate tasks. The points to confirm with your database team are:
- Support window: Confirm your major version against the versioning policy. Version 14 is supported to November 12, 2026, and 15 to November 11, 2027, so check whether an upgrade falls inside your planning window.
- Minor updates: Minor releases do not change the storage format, so updating means replacing executables and restarting. Schedule them at least as often as the quarterly minor release cadence.
- Major upgrades: Choose between dump and restore, pg_upgrade, or logical replication. Logical replication works across major versions and can reduce downtime to several seconds, but it needs its own validation.
- Hot standby and replication mode: Read-only standbys can serve reporting queries. Synchronous replication makes commits wait for standbys, which trades write latency for durability.
- External failover tooling: PostgreSQL does not detect a failed primary or promote a standby by itself, so confirm which tool your team uses and test the promotion path.
Before go-live, confirm the major version, the replication mode and the tool that performs failover.
The GrowthBook application bundles the front end, API and statistics engine in one Docker image, with metadata stored in MongoDB or a compatible database. Upgrades change how experiments are calculated, so each release needs a review before it reaches production. Your application owners and platform team should share the following tasks:
- Image and chart versions: Track the release you run against the GitHub releases page, and pin the image or Helm chart version rather than following the latest tag.
- Changelog review: Read each release note for changes to the statistics engine, data source handling and SDK behavior before you upgrade a staging copy.
- Metadata backup: Back up the MongoDB or compatible database that stores experiment definitions and metric configuration, and test restoring it.
- Query audit: Review the SQL that GrowthBook runs against the warehouse after each upgrade, and confirm that it still runs only SELECT queries and sends back aggregates.
- Edition features: Confirm which controls you need, such as SSO, approval workflows or holdouts, and whether they require the self-hosted Enterprise edition.
Before go-live, confirm the pinned version, the staging upgrade procedure and the owner who signs off each release.
Questions buyers ask before hiring outside help
What does warehouse-native experimentation cost to set up?
The cost comes mostly from people and data work, not from the GrowthBook software itself, which is free to self-host under the Open Source plan. Expect a one-time effort to prepare the warehouse, build the experiment data model, define metrics in SQL and configure access, followed by recurring effort for metric maintenance, upgrades and hosting. The main drivers are how clean your warehouse already is, how many sources feed your experiments, whether you need Enterprise features such as SSO and SCIM, approval workflows or holdouts, and how many metrics you must define and validate. The GrowthBook pricing page lists the self-hosted Open Source plan as free, while Enterprise is custom priced. Ask any partner for a quote that separates warehouse preparation, metric definition, identity integration, hosting, and post-go-live support, and states which Enterprise features are in scope.
How long does a warehouse-native experimentation rollout take?
The duration depends mainly on how ready your data is, so the data work sets the pace more than the GrowthBook installation does. Standing up the application is usually the shorter part. Connecting the warehouse, agreeing on the exposure and event tables, and defining the metrics that decision-makers trust take longer, especially when revenue or conversion figures come from several systems. Plan for analyst review of each metric and a validation experiment that checks the numbers against a known result. Ask a partner to state the timeline in the written scope, with the assumptions about warehouse readiness, the number of sources and the number of metrics named explicitly, so you can see which items would move the date.
What must our team provide before the engagement starts?
Three groups of people need to be available. First, a warehouse administrator who can create a read-only role with SELECT access to the tables used for experiments, and who can confirm which schemas hold exposure and event data. Second, analysts who own the metric definitions, because a metric is only useful if the business agrees what it measures, such as conversion, revenue per visitor or refund rate. Third, a named data owner who can approve access, data location and retention decisions and who signs off on the scope. Without these roles in place, the engagement stalls at the first metric review. Confirm each named person and their time before work is scheduled.
Can our own team run warehouse-native experiments without outside help?
Yes, a team with strong SQL skills and a warehouse administrator can run the open-source stack without an outside partner, provided it has time to learn the GrowthBook data source configuration, the metric definition model and the statistics it reports. Most internal teams struggle less with the installation than with agreeing on metric definitions, handling sample ratio mismatch, avoiding peeking during tests and keeping the Python statistics service, MongoDB metadata store and warehouse connection patched. Outside help is most useful when you need a fixed-scope build with documented decisions, a validation run, or hardening that your security team can review. Ask whether the work is a one-time build, a training handover or a retainer.
Which GrowthBook edition do we need for warehouse-native analysis?
The self-hosted Open Source plan supports warehouse-native analysis, with unlimited users, one project and unlimited API requests, according to the GrowthBook pricing page. The Enterprise edition adds features that many organizations need at scale, including SSO and SCIM, advanced permissioning, approval workflows, multi-armed bandits, safe rollouts, ramp schedules, sticky bucketing and holdouts. Choose the edition by listing your requirements first: identity integration, the number of projects, approval evidence needed by auditors, and whether holdouts or ramp schedules are part of your method. Confirm the current feature list on the GrowthBook pricing page before you buy, since editions change.
How do we verify that only aggregates leave the warehouse?
GrowthBook states that it runs only SELECT queries against your warehouse and transmits only aggregated statistics back to the application, according to its data source documentation. Verification should not rely on that statement alone. Ask for the warehouse query history during a test run, a review of the database role's grants showing read-only access, and a network capture or egress log proving which hosts the application contacts. Check that the SQL generated for each metric produces grouped counts and sums rather than row-level exports, and that no sample of raw user identifiers is written to application logs or the MongoDB metadata store. Document the result as evidence your security or compliance team can retain.
What happens after go-live, including upgrades and support?
After go-live, the platform needs recurring work: applying GrowthBook releases, checking warehouse driver and query compatibility, reviewing metric definitions as products change, rotating credentials, maintaining the MongoDB or managed database layer, and restoring the metadata store in tests. The GrowthBook releases page shows v5.1.0 released on September 22, 2026, so an upgrade plan should name a review cadence rather than assume one. DeployOpen offers ongoing support, upgrades and testing as retainers, and most engagements are fixed-scope with agreed deliverables in writing. Ask any partner what the retainer covers, who responds to incidents, how upgrades are tested before production, and what happens to metric definitions during a version change.
What to ask an implementation partner before signing
Start with the warehouse boundary, because it is the control that most distinguishes this setup. Ask the partner to show how the GrowthBook data source connection is provisioned: a dedicated role with read-only grants, a SELECT-only pattern that matches the GrowthBook data source documentation, and a list of schemas the role can see. Then ask how they verify aggregates-only egress in practice, for example by capturing query logs and network egress during a test run and comparing what leaves the warehouse against the statistics GrowthBook is designed to receive. Ask who owns the warehouse-side credentials after handover and how rotation is recorded. A partner who cannot show you these artifacts in a test environment before signing has not verified them.
Next, ask how exposure data and metric SQL are tested before anyone trusts a result. Exposure tables that record who saw which variant are the most common source of invalid experiments, so ask for the test cases on assignment logging, duplicate exposures, late-arriving events and bot traffic, and for the reconciliation they run against the application's own assignment logs. Ask who owns metric definitions once the engagement ends and whether your analysts will receive written standards for naming, filters and time windows. Ask how the partner handles GrowthBook edition choice: which features the free self-hosted Open Source plan lacks, such as SSO, approval workflows and holdouts, and whether the partner will document the trade-off against your identity and change control requirements in writing.
Finally, make the scope and the operating model explicit. Ask whether the engagement is fixed in scope, with deliverables and acceptance criteria written down before work starts, and what happens when the warehouse proves messier than the discovery phase assumed. Ask what restore testing they include for the warehouse backups, since the ClickHouse backup documentation warns that a backup never test-restored will probably not restore properly, and whether restores are run on a spare cluster with timings recorded. For PostgreSQL metadata stores, ask how they plan upgrades against the supported version list. Last, ask what a retainer covers after go-live: monitoring, GrowthBook and warehouse upgrades, metric review and on-call response. Get the answers in writing, along with the response times they commit to.
How DeployOpen scopes and supports warehouse-native experimentation
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For warehouse-native experimentation, that means connecting GrowthBook to the warehouse the team already runs, agreeing the metric definitions in writing and handing over a setup the data team can operate.
How we scope
- Inventory the warehouse engines, schemas and experiment event tables GrowthBook would query, and confirm read-only access for the analysis role.
- Agree which metrics, guardrails and experiment types are in the first release, with owners named for each SQL definition.
- Record the hosting model, edition choice and identity requirements in a written scope before any work starts.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
How we build
- Deploy the self-hosted GrowthBook stack and its metadata database in the client's cloud account or data center.
- Configure the data source connections and validate that only SELECT queries and aggregated results are used.
- Build and review metric and fact definitions in SQL against a test set of known experiment results.
- Test the setup with representative data and query volumes, including failure and restart scenarios for the stack.
How we hand over
- Document the architecture, data source configuration, metric catalog and the upgrade path for each component.
- Provide a runbook covering access roles, backups of metadata, and how to add a new warehouse or metric.
- Walk the data engineering and experimentation teams through the setup and record the decisions made during scoping.
- Deliver the evidence the client's own auditors or assessors may ask for, without issuing any attestation.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after go-live.
- Plan version upgrades of GrowthBook and the warehouse engine against the vendor changelogs and a pre-production environment.
- Review metric definitions and access changes periodically with the client's data and security owners.
- Confirm with the client which support hours, response terms and upgrade windows apply before signing.
