Optimizely cost vs self-hosted GrowthBook

Optimizely's cost follows traffic. Its plans are custom and priced on monthly active users, and Web Experimentation counts every visitor on a page that loads the snippet, including visitors to pages where no test is running. Your bill therefore moves with site growth, marketing campaigns and the number of pages carrying the tag, not with how many experiments your team runs. Before comparing numbers, ask Optimizely in writing how it defines an MAU in your contract, whether a visitor is counted once per period across products, which domains and environments count, and what happens when traffic spikes above the committed volume.

GrowthBook's paid cloud tiers follow people and projects instead. The GrowthBook pricing page lists Cloud Pro at $40 per seat per month for up to 30 users and 3 projects, and Cloud Starter as free for up to 3 users and 1 project. That $40 figure is a cloud plan price, not the cost of running GrowthBook yourself. The self-hosted Open Source plan has no seat fee, unlimited users and unlimited API requests, but it allows only 1 project. Self-hosted cost is then your own servers, MongoDB, storage, staff time and any Enterprise license, which is custom priced.

The practical decision is to count your people and projects, then check whether the 1-project limit fits. If several products or business units need separate flag sets, the free self-hosted plan may not be enough, and you should ask GrowthBook for an Enterprise quote covering seats, projects and the self-hosted Enterprise features you need, such as SSO and SCIM and approval workflows. Warehouse query volume and infrastructure size still scale with usage, so ask your team to estimate event volume with and without the Optimizely snippet removed, and request that estimate in the quote.

GrowthBook analyzes experiments where your data already lives. According to its data source documentation, it runs only SELECT queries against your own warehouse and transmits only aggregated statistics back, so the query compute that powers each analysis is a recurring cost that you pay to your warehouse provider, not to GrowthBook. Supported sources named in the GrowthBook data source documentation include BigQuery, Snowflake, Redshift, Databricks, ClickHouse, Postgres, MySQL, SQL Server, Athena, Presto or Trino and Vertica. Optimizely's plan does not show a separate line for this work, so the comparison has to add it in explicitly.

Check your warehouse billing model before you put a number next to the GrowthBook license. Some providers charge per byte scanned, some per compute second on a reserved or on-demand cluster, and some bundle compute into a commitment. Ask your data platform team how the tables holding experiment exposure and metric events are partitioned and how often experiment queries refresh, because scan volume and refresh frequency drive the bill up or down. Also confirm whether the warehouse account has a separate compute pool that can be sized for experiment analysis, so that experiments do not compete with dashboards or pipelines for capacity.

Treat this line as part of the total cost of ownership, next to the GrowthBook servers and MongoDB. Ask for an estimate from your warehouse provider based on your expected number of experiments, metrics and analysis cadence, then compare that with the Optimizely events export and storage you would otherwise keep. A practical decision is whether your team already pays for a warehouse with spare capacity, in which case the marginal query cost may be small, or whether experiments would be the main reason to add capacity, in which case the cost belongs squarely in the business case.

Optimizely to GrowthBook has no built-in importer, so the migration is labor you plan and pay for rather than a button you press. The work begins with an inventory of every feature flag, experiment, audience and metric in use, including the web experiments that run through the Optimizely snippet. Each item then has to be recreated in GrowthBook through its API, the application's Optimizely SDK or snippet has to be swapped for the GrowthBook equivalent, and the success metrics have to be rebuilt as SQL definitions against your own warehouse. The sibling migration guide explains the sequence, but the effort depends on what your inventory turns up.

The size of that inventory varies widely between organizations, and the difference matters more than any general estimate. GrowthBook's LaunchDarkly importer documentation warns that advanced setups may include scenarios it cannot handle, and that the application still has to switch SDKs after the import. That warning applies in spirit to any cross-vendor move. Nested prerequisites, custom audiences, mutually exclusive experiments, flags read by back-end jobs nobody remembers, and web tests that depend on Optimizely-specific page targeting each add work. Ask your team to count these before scoping, and treat any item you cannot explain as a risk line in the plan.

Most of the migration cost is one-time labor plus a parallel-run period, during which both platforms serve traffic or results are compared. Parallel running is where recurring cost hides: you pay for Optimizely until cutover, and you run GrowthBook infrastructure and warehouse queries during validation. Ask any implementation partner for a written scope that names the inventory method, the metrics to rebuild, the cutover criteria, the validation window and the handover of runbooks. Confirm with Optimizely the end date and notice terms of your contract, because those set how long the overlap can run.