Open-source alternative to Amplitude Experiment

Open-source alternative to Amplitude Experiment: the short answer

Amplitude's Free and Plus plans allow one active experiment per product, so teams that need several tests running at once start looking for a second option. The two realistic open-source paths are self-hosted GrowthBook, which is MIT licensed outside its enterprise directories, and experiments inside self-hosted PostHog. The deciding question is whether your experiment results should be calculated from your own data warehouse or from events that already flow into your analytics tool. Teams that already run a warehouse usually keep metric logic there, while teams without one often want experiments and analytics in a single product. Answer that question first, because it determines the architecture, the metric definitions and who maintains them.

GrowthBook analyzes each experiment against your own data source, including BigQuery, Snowflake, Redshift, Postgres and ClickHouse. It runs only SELECT queries and transmits aggregated statistics back, so the analysis stays close to the data you already govern. PostHog takes a different approach: experiments sit beside product analytics, session replay and feature flags, so metrics reuse events the platform already collects. PostHog's code is MIT licensed except the ee directory, which needs a PostHog license for premium features on self-hosted instances. Its posthog-foss repository is purged of proprietary code. Check which features each option requires before you commit to either.

Before you run a pilot, confirm three things in writing. First, list the GrowthBook features you need, because holdouts, multi-armed bandits, sticky bucketing, SSO and approval workflows belong to self-hosted GrowthBook Enterprise, not the free Open Source plan. Second, verify whether PostHog's self-hosted build covers the premium experiment features you use, since PostHog states that self-hosted deployments are officially unsupported. Third, decide who will run, upgrade and back up the stack. The cost of either option sits mostly in people and infrastructure rather than in licenses, so ask any implementation partner for a quote built from that written scope.

Which Amplitude Experiment capabilities map to open-source options

This table maps the main Amplitude Experiment capabilities to GrowthBook Open Source, GrowthBook Enterprise and PostHog experiments. Read each row against the plan you would run, since several GrowthBook capabilities are only in the Enterprise tier. Confirm current feature availability for PostHog experiments in your chosen version before you commit.

Capability	GrowthBook Open Source (self-hosted)	GrowthBook Enterprise (self-hosted)	PostHog experiments (self-hosted or Cloud)
Experiment setup and feature flag rollout	Feature flags and experiments in one app, with the Open Source plan limited to 1 project	Same setup model, with approval workflows and safe rollouts added	Experiments built on PostHog feature flags, confirm current feature availability in your version
Targeting and bucketing	Targeting rules and percentage rollouts included; sticky bucketing is not included	Adds sticky bucketing and ramp schedules	Targeting by person properties and flag conditions; confirm sticky bucketing behavior in your version
Statistical analysis	Frequentist and Bayesian analysis run by the bundled Python statistics engine	Same statistics engine, plus multi-armed bandits for adaptive allocation	Built-in experiment results; confirm which statistical methods your version exposes
Metric definitions	Metrics defined against your own warehouse tables and SQL	Same metric definitions, with access controls over who edits them	Metrics drawn from PostHog's own event data; check how custom warehouse metrics are supported
Holdouts and long-running tests	Holdouts not included in the Open Source plan	Holdouts included	Confirm holdout support in your PostHog version before planning long-term control groups
Sequential or adaptive testing	Standard fixed-horizon analysis; no bandits or safe rollouts	Multi-armed bandits and safe rollouts included	Confirm whether sequential or adaptive analysis is available in your version
Warehouse access	Queries your own warehouse with SELECT only and transmits aggregated statistics	Same warehouse-native model, with SSO and SCIM for access control	Runs on PostHog's event store; warehouse-native analysis depends on your PostHog setup
Identity and access	No SSO or SCIM; access managed locally	SSO, SCIM and advanced permissioning included	SSO, audit logs and custom roles are sold as platform packages on PostHog Cloud

When GrowthBook or PostHog fits better

Both options remove the one-active-experiment limit of Amplitude's Free and Plus plans, but they differ in where experiment math runs and what sits around it. Choose by where your event data already lives and how much you want to depend on a vendor for support and premium features.

GrowthBook self-hosted on your warehouse

GrowthBook fits teams that want experiments computed in their own BigQuery, Snowflake, Redshift, Postgres or similar warehouse. GrowthBook runs only SELECT queries and transmits only aggregated statistics, so user-level rows stay in your warehouse. The self-hosted Open Source plan is free with unlimited users and one project. Check that your warehouse holds the exposure and metric events you need, because GrowthBook can only analyze what the warehouse already contains.

GrowthBook Enterprise features

The free self-hosted plan lacks several features that matter once experiments go to production. Enterprise adds SSO and SCIM, advanced permissioning, approval workflows, safe rollouts, holdouts and multi-armed bandits, and these sit in enterprise directories under a separate license. Confirm which of these your review process requires before committing, and ask GrowthBook for a written quote covering the seats and support you need.

PostHog experiments beside analytics

PostHog suits teams that already run PostHog for product analytics, session replay or feature flags, because experiments reuse the same event stream and flags. Results appear next to the funnels and retention reports you already use. The trade-off is that PostHog's self-host documentation describes the Docker Compose hobby deployment as officially unsupported, with no customer support for infrastructure questions, so budget for in-house or partner operations.

PostHog premium features need a license

PostHog's core code is MIT licensed, but premium features in the ee directory need a PostHog license on a self-hosted instance. If you need fully free software, the posthog-foss repository is purged of all proprietary code and features, which may leave out capabilities your experiment workflow expects. Verify the exact feature set of each option against your requirements before choosing a repository.

Metric definitions and migration

Moving an experiment program is mostly a metric problem. GrowthBook's LaunchDarkly and Statsig importers carry over flags and some experiments, but Statsig metric sources are limited to warehouse-native metrics, and the application must still switch SDKs after import. Map each Amplitude metric to a warehouse query or a PostHog insight, and run both systems in parallel for at least one experiment cycle before retiring Amplitude.

How the GrowthBook deployment is built

GrowthBook packages its Next.js front end, Express API and Python statistics engine in one Docker image, so a trial needs one container plus a metadata database. This setup suits proofs of concept, sandbox testing of the statistics engine and early evaluation by a small group of engineers. It is not a production layout, because a single host with a single database has no redundancy and the upgrade and backup steps fall entirely on your team.

One image: the front end, API and statistics engine run together, so there is one version to pin and one container to restart.
Metadata store: GrowthBook keeps experiment and feature metadata in MongoDB or a compatible database, which must be running alongside the container.
Local file uploads: the default file storage writes to the local disk, which is acceptable for a trial but is lost if the host is replaced.
No vendor support path: self-hosted deployments run on your own staff's time, so the trial team must own every restart, log review and version change.
Data source access: the statistics engine still needs a read-only connection to your warehouse to analyze real experiments.

Before trial work starts, confirm the release you will pin in the GrowthBook GitHub releases page and the database version your environment supports in the self-hosting documentation.

Running experiments next to the rest of the analytics stack

Amplitude can keep handling product analytics while experiments move elsewhere, but both systems then count the same users and events. The cards below cover how GrowthBook reads from your warehouse, how PostHog can sit beside Amplitude during a transition, and what must match before results from the two sides are compared.

GrowthBook reads from your warehouse

GrowthBook runs its statistics against your own data source, such as BigQuery, Snowflake, Redshift or Postgres, and sends only SELECT queries and aggregated results back. Amplitude keeps serving dashboards and funnels while the warehouse holds the event tables that experiment metrics are built from. Confirm that your Amplitude event exports or warehouse feeds are complete and current before you point GrowthBook at them.

Two sources of truth

If Amplitude reports a conversion rate and GrowthBook reports a different one for the same metric, teams lose trust in both. Differences usually come from filters, time zones, bot exclusion or attribution windows that were defined separately. Write each metric definition once, record which system owns it, and reconcile a sample of users before any decision relies on the comparison.

Align event definitions

An event named checkout_completed in Amplitude must map to the same warehouse table, property and condition in GrowthBook, or the metric measures something else. Agree on event names, required properties, deduplication rules and how refunds or cancellations are handled. Keep this mapping in a shared document that engineering, analytics and product owners review together.

Match user identifiers

Experiment assignment and metric counting only agree when both use the same user key, such as a stable user ID rather than an anonymous device ID. A mismatch shows up as exposed users who never appear in metric data, which biases results. Check how each SDK sets the identifier after login, and test the join between exposure records and event tables on a small cohort first.

Log exposures consistently

An exposure event records that a user saw a variant, and it is the denominator for every experiment result. If Amplitude receives assignment events but the warehouse does not, or the timing differs, lift estimates will drift. Decide which system writes the exposure record, confirm it fires once per user per experiment, and compare exposure counts across both tools for the same day before you trust results.

PostHog beside Amplitude

PostHog can run analytics, feature flags and experiments in one place, so teams can trial it while Amplitude stays in production. During that period, send the same events to both tools or import history with PostHog's managed migrations, which take at most one year of data per job and do not deduplicate events. Plan the cutover date in advance so that two systems do not both count the same experiment for long.

How metrics and experiment history carry over from Amplitude

Amplitude experiment results and metric definitions do not map one to one onto GrowthBook metrics, so plan to rebuild metrics rather than copy them. Each metric your team relies on needs its event source, conversion window, aggregation, exposure rule and filters written again as SQL against the warehouse table that holds the same events. Then validate baselines before trusting any new result. Run both systems over the same date range, compare exposure counts and conversion rates, and investigate gaps caused by bot filtering, deduplication, timezone handling or identity resolution. Keep the old Amplitude results as a dated archive, since a rebuilt metric is a new definition with its own history.

GrowthBook analyzes experiments in your own data source, running only SELECT queries and sending back aggregated statistics. That means the metric SQL, and the data quality behind it, becomes your responsibility. Data engineers own the query logic and the warehouse tables, while product analysts should sign off on each definition before it is used for a launch decision. Confirm first that the Amplitude event data you need is landed in a supported warehouse such as BigQuery, Snowflake, Postgres or Trino, as listed in the GrowthBook data source documentation. If it is not, the warehouse work comes before any experiment migration.

The importers cover less than a full experiment history. GrowthBook's LaunchDarkly importer brings flags, environments, targeting rules, rollouts and prerequisites into a preview, and its documentation warns that advanced setups can include scenarios it cannot handle and that the application must still switch to a GrowthBook SDK. The Statsig importer covers experiments, but its metric sources and metrics are in beta and limited to warehouse-native Statsig metrics. Amplitude is not described in the importers we reviewed, so ask GrowthBook directly what can be carried over from Amplitude, and run a test migration on a copy of one running experiment. Compare its exposures and results against the Amplitude report before deciding what to move.

Moving running and past experiments off Amplitude

This sequence moves active and archived Amplitude experiments onto GrowthBook, with metrics rebuilt against your own warehouse and a parallel run that confirms the results match before the old flags are retired. The output is a documented experiment history, a working GrowthBook environment and a clean cutover.

Inventory active and archived experiments
The product owner and an engineer list every Amplitude experiment, including its status, variants, targeting, exposure rules and the primary and guardrail metrics attached to it. Archived experiments go on the list too, because their results are often the reason a team later asks what changed. The inventory is done when each experiment has a row that says whether it will be finished on Amplitude, rebuilt in GrowthBook, or kept as a read-only record. Confirm the export options for past results with Amplitude before assuming they are complete.
Confirm the warehouse holds exposure and conversion events
The data engineering team checks that the warehouse receives the events GrowthBook needs: one exposure event per user and experiment with the variant assignment, plus the conversion events behind each metric. GrowthBook reads from your own data source and runs only SELECT queries, so these events must already land there, with user identifiers that join cleanly to exposure records. Note any gap, such as events that exist only in Amplitude or identifiers that changed over time. The step is complete when a sample query returns exposures and conversions for a recent experiment.
Stand up a self-hosted GrowthBook test environment
The platform team deploys GrowthBook in a non-production environment inside your own infrastructure, using the self-hosting guide's Docker image or the official Helm chart for Kubernetes. Metadata is stored in MongoDB or a compatible database, and the documentation suggests a managed service for production, so the team should decide that before going live. Connect the test instance to a copy of the warehouse, then confirm that the data source connection works with read-only credentials. The step is done when a test project can query the warehouse and show results.
Rebuild metrics as SQL in the warehouse
Analysts rewrite each Amplitude metric as a SQL definition that GrowthBook can run against the warehouse, using the same event names, time windows and user definitions. Amplitude's charts are not imported in this form, so each metric needs a written definition and a reviewer who checks it against the original. Compare a few known results from a finished experiment to confirm the SQL reproduces the numbers within expected tolerance. The step is done when every metric on the inventory has a reviewed definition and a reconciled sample result.
Run both tools in parallel on one feature
Choose one low-risk feature and assign users to variants in both Amplitude and GrowthBook, so the same visitors see the same experience while both systems record exposure. The team compares assignment counts, exposure rates and metric results at the end of the run, and documents every difference along with its cause. Differences usually trace back to identifiers, time zones, deduplication or assignment logic, so resolve each one before expanding the test. The step is complete when the results agree and the team signs off on the method.
Switch SDKs and migrate flags
Engineers replace the Amplitude Experiment SDK calls with a GrowthBook SDK in the application code, since the importers do not swap client libraries for you. Where a flag system is involved, the team can use the importer documented for it, but advanced setups may include scenarios the importers cannot handle, such as custom targeting, nested prerequisites or unusual rollout logic. Each imported flag is checked against its source configuration before it goes live. The step is done when the application runs on GrowthBook in staging with the expected variant for each test user.
Retire the Amplitude experiments
Once each active experiment is finished or moved, the team stops the remaining Amplitude assignments, removes the old SDK and disables the flags that no longer serve a purpose. Keep an export of the final results and the experiment inventory from the first step, since Amplitude's retained data is not a substitute for a record your team controls. Document who approved each retirement and where the archive is stored. The step is complete when no production code calls Amplitude Experiment and the archive is verified.

What does it cost and what does the work need from us?

What costs are one-time and what costs recur when self-hosting GrowthBook?

The GrowthBook software itself has no license fee on the Open Source plan, so the costs are the infrastructure it runs on, the database for its metadata, the data warehouse compute that runs experiment queries, and the people who set it up and maintain it. Setup, instrumentation and metric definitions are one-time work. Hosting, database service, warehouse queries, upgrades and on-call time recur every month. Ask any provider to split its quote into these two groups so you can see what you will keep paying after launch.

How does GrowthBook Open Source compare with Enterprise pricing?

The self-hosted Open Source plan is free, with unlimited users, 1 project and unlimited API requests. Enterprise is priced by quote, so there is no published figure to compare against. Self-hosted Enterprise adds SSO and SCIM, advanced permissioning, approval workflows, multi-armed bandits, safe rollouts, ramp schedules, sticky bucketing and holdouts. Check whether your experiments need any of these before you decide, and ask GrowthBook for a written Enterprise quote if they do. The GrowthBook pricing page lists the current plan contents.

What makes a GrowthBook deployment take more effort?

Effort rises with the number of metrics, the size of the warehouse tables those metrics query, the number of projects you need, and whether you require SSO or approval workflows. Each metric adds a query that runs against your warehouse, so large fact tables and many metrics increase both compute cost and tuning work. Multiple projects beyond the one included in the free plan need Enterprise. Ask your partner to estimate effort per metric source and per project, not as one total.

Can an internal team run GrowthBook alone?

A team with container, database and data warehouse experience can usually deploy GrowthBook from its Docker image or official Helm chart, but the harder work is in the data: reviewing the SELECT-only query permissions, defining metrics that match your business logic, and agreeing how experiment results are read. Most teams underestimate the time for metric definitions and for hardening access. A partner can take that work under a fixed-scope agreement, while your team keeps ownership of the metrics and the release process.

How much time should a quote be scoped against?

Scope the quote against the work, not a fixed duration. The main variables are the number of data sources, the metrics to migrate or define, whether you move feature flags from another tool (GrowthBook documents importers for LaunchDarkly and Statsig, each with limits), and whether SSO and Enterprise features are required. Ask the provider to state its assumptions and the milestones it will sign off on, and to list what your team must provide, such as warehouse access and identity provider details.

What should a written scope for this work include?

A written scope should name the GrowthBook version and deployment method, the hosting environment, the database service, each warehouse data source and its access model, the metrics in scope, the number of projects, and the SDK changes in your applications. It should also state acceptance tests, backup and upgrade responsibilities, and what is excluded, such as Enterprise features or migrations from another flag tool. Ask for the list of your responsibilities alongside the partner's, so both sides know who owns each step.

What ongoing support does a self-hosted deployment need?

PostHog's self-host documentation states that self-hosted deployments are officially unsupported and that PostHog does not offer support on them, so that choice must be planned for on its own terms. For GrowthBook, the Open Source plan has no vendor support, so you need your own on-call coverage or a retainer with a partner. Ongoing support, upgrades and continuous testing are available from DeployOpen as retainers, and the scope of each should be written down before work starts.

Which features need GrowthBook Enterprise

The free self-hosted Open Source plan of GrowthBook covers experimentation with unlimited users, one project and unlimited API requests, but several controls that regulated teams often ask for sit only in the self-hosted Enterprise tier. According to GrowthBook's pricing page, those controls are SSO and SCIM, advanced permissioning, approval workflows, multi-armed bandits, safe rollouts, ramp schedules, sticky bucketing and holdouts. Before you commit to the free tier, map each one against your change-control and access requirements rather than assuming the open-source feature set is enough.

Of these, SSO and SCIM, advanced permissioning and approval workflows usually matter most for regulated teams, because they determine who can start, approve and stop an experiment and whether access follows your identity provider's joiner and leaver process. Safe rollouts, ramp schedules and holdouts affect exposure to customers and the ability to keep a control group for measurement. Sticky bucketing keeps users in the same variant across sessions, which matters for consistent analysis. Ask GrowthBook which of these your workflow needs to be enforced in the tool rather than handled by a manual procedure.

The LICENSE file states that code outside the enterprise directories (packages/back-end/src/enterprise, packages/front-end/enterprise and packages/shared/src/enterprise) is MIT Expat licensed, while those directories fall under the GrowthBook Enterprise License. Confirm the license terms with GrowthBook before deployment, including what a self-hosted Enterprise license permits in your environment, and have your legal team review the terms. Plan your evidence for access reviews and change approvals against the features your tier actually includes.

How DeployOpen scopes and delivers experimentation replacement

DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For experimentation, that means agreeing in writing which experiments, metrics and data sources move, then building the platform and handing it over with the runbooks your team needs.

How we scope

Inventory every active and planned Amplitude Experiment, its exposure rules and the metrics each one reads.
Confirm which warehouse or event store holds the data GrowthBook or PostHog would query, and who may grant read access.
Agree in writing whether GrowthBook Enterprise features or PostHog paid ee modules are in or out of scope.

How we build

Deploy the chosen platform in your environment, including the Docker or Helm deployment and its metadata database.
Recreate experiments and metrics, then check that results match a sample of existing Amplitude readouts before cutover.
Wire the SDK changes into your application and test assignment, exposure logging and statistics in a staging environment.

How we hand over

Deliver written configuration, access model, metric definitions and a record of which experiments were migrated or retired.
Document the SELECT-only warehouse permissions and the aggregated-statistics data flow so your security team can review them.
Train the owners who will create and read experiments, and list the open items that remain with your team.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped separately from the build.
Plan version upgrades of the platform, testing each release against your experiment definitions before rollout.
Confirm with each vendor which support tier applies, since self-hosted PostHog is not supported by PostHog itself.

Open-source alternative to Amplitude Experiment