Eppo cost vs self-hosted GrowthBook: where the money actually goes
The license line is only one part of the cost, and warehouse compute is paid for by both tools. If your renewal notice from Eppo is the main number on the table, you are comparing one invoice against a set of costs that land in different budgets. Eppo does not publish its prices, so the only valid baseline is the written quote your procurement team holds. On the GrowthBook side, the self-hosted Open Source plan is free with unlimited users, 1 project and unlimited API requests, according to the GrowthBook pricing page. Self-hosted Enterprise is a separate, custom-priced line item, so ask GrowthBook for a quote if you need it.
Warehouse compute does not disappear when you change tools. Experiment analysis runs SELECT queries against your own warehouse in either case, so the query spend for metrics and results stays with your cloud or warehouse bill. What changes is who runs the rest. Self-hosting moves the GrowthBook application, its MongoDB or compatible metadata store, backups, upgrades, TLS, monitoring and on-call onto your team. The GrowthBook self-hosting documentation suggests a managed MongoDB service such as MongoDB Atlas or AWS DocumentDB for production, which is a recurring cost you should price separately. Ask your platform team to estimate the engineering hours for upgrades and incident response, since those are real recurring costs even when no license fee applies.
Decide early which Enterprise features your team actually needs, because they are the main reason the self-hosted cost moves from zero. The free Open Source plan does not include SSO and SCIM, advanced permissioning, approval workflows, multi-armed bandits, safe rollouts, ramp schedules, sticky bucketing or holdouts. If you rely on SSO, audited approvals for production flags, or holdouts for measuring long-term impact, those items belong in the GrowthBook quote. Confirm with GrowthBook which edition and seat model applies to your team size, and ask Eppo's account team to itemize what their renewal covers, including support tiers and any Datadog-related add-ons, so the two totals can be compared line by line.
Which cost components change when you move from Eppo to self-hosted GrowthBook
This table compares each cost component on the Eppo side with the self-hosted GrowthBook side and marks whether it is one-time or recurring. Read it as a checklist for building a quote: the warehouse compute line stays largely the same on both sides, so the decision usually turns on the subscription, hosting and migration rows. The GrowthBook list prices cited here come from the GrowthBook pricing page, and the Eppo figures should come from your own Datadog agreement.
| Cost component | Commercial side (Eppo by Datadog) | Self-hosted side (GrowthBook) | One-time or recurring |
|---|---|---|---|
| Subscription or license | Annual or monthly Datadog contract covering Eppo seats, usage and support terms. Confirm the exact unit and renewal date in your order form. | Open Source tier is free, with unlimited users, 1 project and unlimited API requests. Self-hosted Enterprise is custom priced (GrowthBook pricing page). | Recurring |
| Warehouse compute | Queries run against your warehouse for analysis and metric computation. Eppo sends SELECT queries and aggregates results in the same way. | GrowthBook runs read-only SELECT queries against your warehouse and transmits only aggregated statistics. Compute spend is similar in shape, so compare query volume, not tool price. | Recurring |
| Hosting the GrowthBook image | Not applicable. Eppo runs the platform as a hosted service. | One Docker image bundles the front end, API and statistics engine. Runs on your cloud, data center or Kubernetes via the official Helm chart. | Recurring |
| MongoDB or compatible database | Not applicable. Metadata sits in Eppo's hosted environment. | Stores GrowthBook metadata. The docs suggest a managed service such as MongoDB Atlas or AWS DocumentDB for production. | Recurring |
| File storage | Not applicable as a separate charge that you manage. | Local disk, Amazon S3 or Google Cloud Storage for file uploads, chosen during setup. | Recurring |
| Migration effort | Limited to your internal time while Eppo remains live. Confirm whether Datadog offers migration help under your contract. | Rebuilding flags, metrics and definitions, swapping SDKs and logging callbacks, and re-running live experiments. The LaunchDarkly importer does not cover every advanced setup, so budget for manual rework. | One-time |
| Internal operations | Vendor operates the service, upgrades and availability. Your team manages definitions and access. | Your team or a partner owns uptime, backups, access control, patching and monitoring of the GrowthBook and MongoDB tiers. | Recurring |
| Upgrades and support | Included in the subscription at the support level you buy. Confirm response expectations in writing. | Upgrades follow GrowthBook releases, for example v5.1.0 released September 22, 2026. Paid support or a retainer covers testing and rollout of each release. | Recurring |
What moves the comparison most for your team
Seats, Enterprise features, warehouse load and in-house skills each push the total cost of self-hosted GrowthBook up or down, and they do not move in step. Work through them in order before you compare any subscription line against your own run costs.
Seat count and user roles
GrowthBook's paid cloud tiers bill per seat, while the self-hosted Open Source plan allows unlimited users. Your seat count therefore changes the Eppo subscription comparison far more than it changes the self-hosted licence cost. Count people who edit flags, define metrics and read results, and separate them from viewers who only need dashboards. Ask Eppo for its seat terms in writing so the two sides are compared on the same user population.
Projects and experiment volume
The self-hosted Open Source plan includes 1 project. If your teams run several products or business units as separate projects, you will need the paid tier or a single shared project with naming discipline. Experiment volume drives analysis runs, which drive warehouse compute and statistics engine load. Estimate experiments per month and concurrent experiments before comparing platforms, and confirm how Eppo meters them.
Enterprise features you actually need
SSO and SCIM, advanced permissioning, approval workflows, holdouts, safe rollouts, ramp schedules and sticky bucketing sit in the self-hosted Enterprise plan, not the free edition. List which of these your governance model requires, such as SSO enforcement for auditors or approvals before production changes. Requirements that are optional can often be met with process; requirements that are mandatory set the licence cost. Confirm each feature against the current GrowthBook pricing page.
Warehouse query volume and table size
GrowthBook runs read-only SELECT queries against your own warehouse, so compute is paid to your warehouse provider under either tool. Larger assignment and event tables, more metrics and more frequent refreshes raise that bill. Because both platforms spend the same warehouse compute on the same data, this line is shared rather than a difference between them. Ask your data team to size query cost per experiment and to confirm the refresh schedule.
Control plane availability needs
Flags are evaluated in your applications, but the GrowthBook service, its MongoDB metadata store and the SDK update path matter during rollouts and incidents. Higher availability targets mean redundant nodes, managed or replicated MongoDB, and on-call coverage, each with a recurring cost. Decide what must keep working when the GrowthBook UI or API is down, and confirm how cached flag payloads behave in your SDK configuration.
In-house Kubernetes, MongoDB and statistics skills
Self-hosting moves operations labour onto your team: running the Helm chart on Kubernetes, operating MongoDB or a managed equivalent, upgrading releases and validating statistics configuration. Staff who already run these systems lower the internal cost substantially, while a gap means paying a partner or hiring. Inventory the skills honestly, including who would own experiment statistics checks. Use this inventory to decide whether the savings from dropping the subscription survive the labour line.
Why warehouse compute is a cost both tools share
Warehouse compute is the one cost line that does not change much when you move from Eppo to self-hosted GrowthBook, because both tools read experiment assignments and events from your own warehouse and run their statistics there. GrowthBook runs read-only SELECT queries against sources such as BigQuery, Snowflake, Redshift and Databricks, and transmits only aggregated statistics back, so the query bill is paid to your warehouse provider under either tool. The decision to move should therefore not hinge on an assumption that one product is cheaper to compute. Confirm this with your warehouse team before the renewal conversation.
Four things drive how much compute an experimentation tool spends: the number of metrics evaluated per experiment, how often results refresh, how many experiments run at once, and how well the source tables are partitioned and filtered by date. A metric that scans a full events table on every refresh costs far more than one that reads a partitioned day range. Ask Eppo, in writing, which queries it runs against your warehouse for each metric, how often each runs, and which service account or role executes them. Then ask the warehouse team for query history filtered to those roles over a representative month, grouped by query text, so you compare actual scans and slot or credit use rather than estimates.
Once you have both sets of logs, plan the comparison as a like-for-like test. Run GrowthBook against a copy of a recent experiment's metrics in a non-production dataset, record bytes scanned or credits consumed per refresh, and compare with Eppo's logged queries for the same definitions. Differences often come from definitions rather than the product, such as an unbounded date range or a metric that rejoins the same table several times. Until those logs exist, state the compute line as unknown in your business case instead of assigning it to either side.
How to build the comparison with your own numbers
This sequence turns the renewal quote and your warehouse bills into a like-for-like, multi-year comparison of Eppo against self-hosted GrowthBook. Each step produces a figure you can check, so the final totals reflect your environment rather than published list prices.
Export current Eppo invoice lines and renewal quote
Ask your Eppo account owner or finance contact for the current invoice lines and the written renewal quote, including every line item, the billing unit and the term. Ask Datadog's sales team to confirm in writing whether the renewal terms, support level and any bundled Datadog products are unchanged after the acquisition. You are done when you hold a document that lists each recurring charge, its unit and its contract end date, with nothing left as a verbal estimate.
Inventory seats, projects, experiments and metrics
Count the people who need editor or viewer access, the Eppo projects or workspaces, the active and archived experiments, the feature flags and the metric definitions that would need rebuilding. Pull these counts from Eppo's admin views and your own experiment tracker, and note which experiments are live. The output is a single inventory sheet that you can match against GrowthBook's plan limits on its pricing page, where the self-hosted Open Source plan lists one project and the Enterprise tier adds features such as SSO and SCIM.
Measure warehouse spend attributable to experimentation
Both Eppo and GrowthBook run their analysis queries against your warehouse, so this cost stays roughly the same across the two options and belongs in the comparison as a shared line. Pull query history from your warehouse (for example, Snowflake, BigQuery or Redshift) for a representative sample period, filter for the service accounts and tables that Eppo uses, and total the compute and storage attributed to experiment analysis. Confirm with your data platform team how these costs are tagged, because the figure you get will drive how much the comparison depends on it.
Size the GrowthBook hosting footprint
Using GrowthBook's self-hosting documentation as the reference, list each component you will run: the single Docker image that bundles the Next.js front end, Express API and Python statistics engine, or the official Helm chart if you run Kubernetes. Add the MongoDB-compatible metadata store, decide between self-managed MongoDB and a managed service, and choose file storage (local, Amazon S3 or Google Cloud Storage). Ask your cloud or infrastructure team to price each component in your own accounts. You are done when every component has a named owner and a cost line.
Add migration and internal effort as a one-time line
Estimate the one-time work: rebuilding metrics and flags, swapping SDKs and logging callbacks, re-running live experiments, and any consulting or implementation partner scope. GrowthBook's LaunchDarkly importer and Statsig importer can move flags and experiments, but its documentation notes that advanced setups may need manual work and that the application must still switch SDKs. Record the internal hours by role, plus any external scope agreed in writing with a provider, and label this as a one-time cost so it does not inflate the recurring total.
Add recurring operation, upgrades and support
List the ongoing costs that continue after migration: infrastructure runtime, database backups, monitoring, on-call coverage, GrowthBook upgrades and any Enterprise license or support agreement. Check GrowthBook's GitHub releases page to see how often new versions ship and plan a regular upgrade window for them. Ask whether you need Enterprise features such as SSO, SCIM, approval workflows or holdouts, because those change the recurring license line. The output is a monthly or annual operating budget that you can set beside the Eppo subscription.
Compare totals over the same horizon
Build a table with the same time horizon on both sides, for example three years, and show Eppo subscription, shared warehouse compute, GrowthBook hosting, one-time migration and recurring operation as separate rows. Run the comparison twice: once with the current Eppo renewal quote and once with a sensitivity case where the quote rises. Mark which inputs you verified in writing and which you estimated. The finished table is the decision document, and it shows where the answer depends on warehouse compute or internal staffing rather than on the license alone.
Free self-hosted, Enterprise self-hosted or stay on Eppo
The free self-hosted Open Source plan is the lowest license cost on the GrowthBook pricing page. It is free with unlimited users, one project and unlimited API requests. The software is MIT licensed outside GrowthBook's enterprise directories, so the cost you carry is infrastructure, operations and the work of building experiments, not a seat fee. The plan suits a single product area, a pilot or a team that wants to prove the warehouse-native workflow before committing budget.
- What it covers: the core experiment analysis, feature flags for one project, and SDK evaluation within the open-source feature set.
- What it does not cover: SSO and SCIM, advanced permissioning, approval workflows, multi-armed bandits, safe rollouts, ramp schedules, sticky bucketing and holdouts, all of which the GrowthBook pricing page lists as Enterprise features.
- Recurring costs you still pay: compute and storage for the GrowthBook image, the MongoDB or compatible database, backups, patching and on-call time for upgrades such as the v5.1.0 release.
- Warehouse compute: GrowthBook runs SELECT queries against your own warehouse, so the same query spend you already pay for experiments continues under this plan.
- Get in writing: confirm the project limit applies to your deployment model, and ask GrowthBook which features you would lose if your second product team needs a second project.
Before relying on this tab, confirm the current plan limits on the pricing page, since a second project or a missing governance feature may push the decision toward Enterprise.
The self-hosted Enterprise plan keeps GrowthBook running in your infrastructure and adds the governance and experimentation features that regulated teams usually ask for. GrowthBook's pricing page lists it at custom pricing, so the cost is set by a written quote rather than a public rate. Expect the license to be a recurring line item, with the MongoDB, hosting and warehouse costs unchanged from the free path.
- What it adds: SSO and SCIM, advanced permissioning, approval workflows, multi-armed bandits, safe rollouts, ramp schedules, sticky bucketing and holdouts.
- Licensing scope: the enterprise directories fall under the GrowthBook Enterprise License, so ask legal to review those terms alongside the MIT core.
- Recurring costs: the subscription, support terms, and the time your platform team spends on identity integration and permission design.
- One-time costs: SSO and SCIM setup, permission model design, and migrating flags and metrics from Eppo.
- Get in writing: the price basis (seats, projects or another unit), renewal and uplift terms, what support is included, and which features are in scope for your deployment.
Ask for the quote against your actual user count and deployment model, and confirm in writing which Enterprise features are included in the version you will run.
Staying on Eppo keeps the current workflow, the current vendor contract and the current cost basis, with the change that Eppo is now sold by Datadog. The decision depends on what Datadog commits to for the product and integrations, which is a question for Datadog and not something this page can settle. Renewal terms will set the recurring cost, and you should compare them with the self-hosted paths using the same warehouse compute assumptions.
- What stays the same: your assignment logs and fact tables remain in your warehouse, and you keep the current experiment workflow.
- What changes: the product owner is Datadog, so roadmap, pricing and integration priorities may shift.
- Recurring costs: the Eppo subscription, warehouse compute for experiments, and internal time spent on the existing setup.
- Lock-in exposure: flag definitions, metric definitions and experiment write-ups live in Eppo, so the exit effort grows with every quarter you stay.
- Get in writing: the renewal price and term, the support and data export commitments, and how Datadog plans to handle integrations if you are not on Datadog.
Before renewing, ask Datadog for written answers on continued support, data export, and pricing changes, then compare those answers with the self-hosted costs above.
Questions buyers ask before comparing Eppo and GrowthBook costs
How much effort does moving from Eppo to self-hosted GrowthBook take?
The effort depends mostly on how many experiments, metrics and flags you run, how many warehouses and data sources you connect, and how much of your current setup is written as code. Eppo already reads your own assignment logs and fact tables, so the warehouse work is often smaller than a full migration. The larger share is usually rebuilding metric definitions, recreating flags and swapping SDKs and logging callbacks in each application. Ask for a written inventory of these items before anyone estimates the work, because the count of live experiments is the variable that moves the estimate most.
Can our internal team run the GrowthBook move without outside help?
A team with platform engineering experience and someone who owns experiment analysis can often do the deployment and the first experiments on its own. GrowthBook documents a Docker image and an official Helm chart, so the hosting work is familiar to most infrastructure teams. The harder parts are usually the statistics configuration, the metric rebuild and the cutover of live experiments without losing assignment history. Check whether your team has capacity for those tasks alongside its normal workload. DeployOpen plans and implements self-hosted platforms in the client's own infrastructure under a fixed scope agreed in writing, so you can compare doing it internally with a scoped engagement.
What does self-hosting GrowthBook require from our team?
You need a place to run the GrowthBook image or Helm chart, which can be Kubernetes or a Docker host, and a MongoDB or compatible database for metadata. GrowthBook's self-hosting documentation suggests a managed service such as MongoDB Atlas or AWS DocumentDB for production. You also need read access to the warehouse that holds your assignment and event data, with credentials that allow only the SELECT queries GrowthBook runs. Finally, assign an owner for statistics settings and metric definitions, since those decisions shape every result. Confirm each of these against your own environment and security policies before you size the work.
Is the free GrowthBook plan enough given its one-project limit?
The free self-hosted Open Source plan includes unlimited users and unlimited API requests, but it allows only one project. That fits a single product area or a small evaluation. If several teams run experiments in separate products, you will either combine them into one project or move to the self-hosted Enterprise plan. Map your current Eppo projects and count how many must stay separate, including their permissions and data sources. Then compare that count with the GrowthBook pricing page before you assume the free tier covers your setup.
Which costs are one-time and which recur after the move?
One-time costs include the migration work, metric and flag rebuilds, SDK changes and validation of results against Eppo during a parallel run. Recurring costs include the infrastructure that hosts GrowthBook and MongoDB, backups, upgrades, monitoring, on-call coverage and any Enterprise subscription. Warehouse compute is a recurring cost under both options, because the experiment queries run in your warehouse either way. Ask for each item to be listed separately so you can see which parts scale with users, experiments or data volume.
How do we get a comparable quote from Eppo?
Start by writing down the units that drive your current Eppo bill, such as seats, experiments, metrics, warehouse connections or event volume, and ask Eppo by Datadog to price against those same units. Request the terms in writing, including what is included in support, data retention and any Datadog product bundling. Ask whether renewal pricing differs from the first-year quote. Eppo does not publish the figures in this comparison, so the quote is the only source for its subscription cost. Put both quotes next to the same internal estimate for hosting and staff time.
Do GrowthBook Enterprise features change the cost comparison?
They can, because several features that matter for mature experimentation programs are listed only on the self-hosted Enterprise plan. These include SSO and SCIM, advanced permissioning, approval workflows, multi-armed bandits, safe rollouts, ramp schedules, sticky bucketing and holdouts. If your current Eppo use depends on any of these, the Enterprise subscription becomes a recurring line item in the GrowthBook total. Confirm the Enterprise price directly with GrowthBook, since the pricing page lists it as custom. Also check the GrowthBook LICENSE, because the enterprise directories fall under a separate license from the MIT-licensed core.
What happens to our costs if we stay on Eppo?
If you stay, your costs continue on the current subscription and renewal terms, and your exposure depends on how Eppo's roadmap and packaging change after the Datadog acquisition. Your warehouse compute cost continues either way, so staying does not remove that line. Ask Eppo for its renewal price increase limits, its support commitments and how it plans to handle integration with Datadog products for teams not using Datadog. Write down the date you would need to decide, so the choice to stay is made on purpose rather than by default.
What the one-time migration costs and what it recurs as
The migration is a one-time project, and its size depends mostly on how many experiments, flags and metric definitions your team has built in Eppo. Start by counting them: live and recently concluded experiments, active feature flags, each shared metric and each guardrail. Each item needs a rebuilt definition in GrowthBook, a check that the same warehouse table and column produce the same result, and a decision about whether a running experiment is restarted or allowed to finish in Eppo first. Plan a sample of recent experiments to re-run in GrowthBook and compare against Eppo's published results before you trust the new setup. The count also tells you how much of the work is engineering time (SDK swaps, logging callbacks in the application) and how much is analytics time (metric and statistics setup).
Unlike the LaunchDarkly and Statsig paths, GrowthBook's importers do not read Eppo projects, so there is no automated transfer of flag definitions, targeting rules or metrics. The GrowthBook LaunchDarkly migration guide and the Statsig guide describe importers that work through each vendor's API, and the LaunchDarkly importer itself warns that advanced setups may include scenarios it cannot handle and that the application must still switch from the LaunchDarkly SDK to a GrowthBook SDK after the import. Assume the same limits apply to anything you rebuild by hand. Ask your engineers to list every Eppo flag that uses prerequisites, percentage rollouts or custom attributes, since those are the most likely to need manual translation and retesting.
How DeployOpen scopes a fixed-price GrowthBook implementation
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure. For a move from Eppo to self-hosted GrowthBook, we start from a written scope that separates the GrowthBook hosting work from the warehouse compute and metric rebuilding that your team owns, so the cost picture is clear before any work begins.
How we scope
- Inventory the Eppo features, metrics and experiments in use, and which ones need GrowthBook Enterprise features.
- Confirm the warehouse, its read-only access model and the compute budget your team already pays for.
- Agree deployment targets for GrowthBook and MongoDB, including cloud account, cluster or air-gapped network.
How we build
- Deploy GrowthBook from its Docker image or official Helm chart, with a managed or self-run MongoDB database.
- Connect GrowthBook to the agreed data source and validate that queries return the aggregated statistics you expect.
- Recreate metric definitions and flag configuration, then test a small set of experiments against Eppo results before cutover.
How we hand over
- Document architecture, configuration, backup and upgrade procedures, and the SDK and logging changes in your application code.
- Record which cost components are one-time, such as migration effort, and which recur, such as hosting and warehouse queries.
- Walk your platform and data teams through operation so they can run upgrades and troubleshoot without us.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, agreed separately from the fixed-scope build.
- Ask any quote to itemize hosting, database, migration, testing and retainer lines so you can compare them against your Eppo renewal.
- Confirm with GrowthBook which features your plan includes, since self-hosted Enterprise features are priced separately by GrowthBook.
