Optimizely vs PostHog: when each option fits a product team
A product team that wants experiments, product analytics and session replay in one place usually reaches this comparison because a renewal is coming up or a data residency question has surfaced. Optimizely fits when the priority is vendor-supported experimentation and an enterprise support contract with a named vendor accountable for incidents, upgrades and roadmap. Its Feature Experimentation and Web Experimentation products are sold on custom, MAU-based plans, so the team should ask for the written scope and a quote before assuming the fit. Self-hosted PostHog fits when event data must stay in your own infrastructure and analytics and experiments need to be joined in one tool. Its feature flags and experiments sit alongside product analytics, session replay and surveys, which removes a separate integration between a flag service and an analytics stack.
The free self-hosted path has limits that should shape the decision. PostHog's self-host documentation describes the free Docker Compose (hobby) deployment under the MIT license, installed with a deploy-hobby script, and recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage. The README says open-source deployments should scale to approximately 100k events per month and recommends PostHog Cloud above that. Self-hosted deployments are officially unsupported, and PostHog does not offer customer support for product or infrastructure questions on them. A team that needs a named support contract, or that lacks the people to operate, patch and back up the stack, should either budget for an outside operator or choose a hosted option. Confirm the event volume you expect for the next two years, the support model your risk team requires, and whether the premium directories in the ee/ code are needed, since those fall under a separate PostHog license.
The decision turns on four questions: expected event volume, the support model you need, whether experiment analysis must run on your own warehouse, and whether your team can run the stack yourself. If analysis should be warehouse-native, so that experiment statistics are computed by queries against data that never leaves your warehouse, GrowthBook is the better experimentation choice, and it can sit beside a separate analytics tool. GrowthBook's free self-hosted Open Source plan includes one project with unlimited users, while SSO, SCIM, approval workflows and holdouts require the self-hosted Enterprise plan. Write down which of these questions carry weight for your team before requesting a quote, because the answers decide whether one tool or two is the right architecture.
Which option fits which scenario
This table maps common product team needs to the better fit between Optimizely, self-hosted PostHog and self-hosted GrowthBook. Read each row against your own event volume, support expectations, data location and analysis model, since the reasons cite specific facts about each option.
| Scenario | Better fit | Why |
|---|---|---|
| Product team wanting analytics, replay and experiments in one tool | Self-hosted PostHog or PostHog Cloud | PostHog's README groups product analytics, session replay, feature flags and experiments in one product, so one event stream serves all four uses. |
| Team needing vendor-backed support | Optimizely or PostHog Cloud | PostHog's self-host documentation says self-hosted deployments are officially unsupported and that PostHog offers no customer support for them. Confirm support terms with Optimizely in writing. |
| Team with high event volume | PostHog Cloud, or GrowthBook with a warehouse | PostHog's README says open-source deployments should scale to approximately 100k events per month and recommends PostHog Cloud above that. GrowthBook's analysis runs in your warehouse, so volume is governed by warehouse capacity. |
| Team needing warehouse-native analysis | Self-hosted GrowthBook | GrowthBook runs read-only SELECT queries against your own data source and transmits only aggregated statistics. PostHog stores its events in its own ClickHouse-backed stack. |
| Team with strict data residency | Self-hosted PostHog or GrowthBook, confirmed against your own region | Self-hosted deployments stay in infrastructure you control. PostHog Cloud offers US (Virginia) and EU (Frankfurt) regions, so confirm which region meets your residency rules before choosing hosted PostHog. |
What the free self-hosted PostHog deployment is sized for
The free self-hosted PostHog deployment is a sizing boundary, not a production tier for a growing product team. PostHog's self-host documentation offers a Docker Compose hobby deployment under the MIT license, installed with a deploy-hobby script, and recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage. Treat those figures as the minimum starting point you need to confirm against the current self-host documentation before you size hardware, then add capacity for your own event volume and retention.
The README is more specific about scale. It says open-source deployments should handle approximately 100k events per month and recommends moving to PostHog Cloud above that level. If your Optimizely Feature Experimentation or Web Experimentation traffic is already flowing into PostHog next to product analytics and session replay, count events across all of those products, not just the experiment exposures. A team that crosses the threshold on paper has three real options: pay for PostHog Cloud, move to a larger self-managed design that you build and operate, or split experimentation onto a separate tool such as GrowthBook. Ask PostHog for current Cloud pricing for your event volume before you decide, and cost the self-managed option with your own engineers' time included.
Plan for the Kubernetes boundary early. PostHog's self-host documentation says new Kubernetes deployments of its paid self-hosted product are no longer supported, so a platform team that standardizes on Kubernetes should not assume a Helm-based paid design is available. Self-hosted deployments are also officially unsupported, and PostHog does not provide customer support for product or infrastructure questions on them. Your runbook, on-call rotation and upgrade testing therefore sit with your team or your implementation partner from day one.
What the lack of support for self-hosted PostHog means for you
PostHog's self-hosted product is sold without vendor support for product or infrastructure questions, so the operating burden lands on your team or a partner you contract. The cards below cover who answers upgrades and incidents, which features need a license, and how to move between self-hosted and Cloud without losing control of your data.
Officially unsupported deployments
PostHog's self-host documentation states that self-hosted deployments are officially unsupported and that PostHog offers no customer support for product, infrastructure or other questions on self-hosted instances. For an Optimizely replacement, that means the experiment that stops reporting, or a flag service that fails during a release, has no vendor escalation path. Before you commit, confirm in writing with PostHog what, if anything, its sales team will cover for your self-hosted setup.
Who answers upgrades and incidents
With no vendor support, every upgrade, outage and bug report becomes an internal ticket. Name an owner for the PostHog stack, usually platform engineering, and document who is on call for the event ingestion path, the database and the feature flag service. Experiments that depend on accurate events are only as trustworthy as the team watching ingestion, so list who checks event volume and dropped data after each release.
Internal skills or a partner contract
If your team does not already run ClickHouse, PostgreSQL, Redis and Kafka-class services in production, the realistic options are to build that skill or to contract an implementation partner for installation, hardening, backups and upgrades. A partner engagement is typically fixed scope and is quoted from written requirements, so the scope should state who patches the host, who restores from backup and what happens during a PostHog version upgrade.
Enterprise features need a license
The MIT license covers most of the PostHog repository, but content in the ee/ directory is under a separate license. The README states that premium features from ee/ on a self-hosted instance require a PostHog license. Check which features your rollout depends on, such as SSO, audit logs, custom roles or project permissions, because PostHog sells these as platform packages, and treat any gap as a cost line in your model.
The posthog-foss option
If your policy requires fully free software, the PostHog README points to the posthog-foss repository, which is purged of all proprietary code and features. That choice removes the license question but also removes the premium features, so access controls and admin tooling must be covered by other components. Confirm that the features your experiments need exist in that edition before you build your architecture around it.
Moving between self-hosted and Cloud
PostHog recommends migrating to PostHog Cloud once open-source deployments grow beyond approximately 100k events per month, and the Cloud free tier includes the first 1 million analytics events each month. Plan the move in both directions: managed migrations import historical events from Mixpanel or Amplitude but do not deduplicate them, and imported event data cannot be selectively deleted. Decide early whether Cloud, with its US (Virginia) or EU (Frankfurt) region, is acceptable for your data residency rules.
Where your event data lives under each option
With Optimizely, your experiment and event data lives in a vendor-hosted service, and your control is limited to the contract, the data processing terms and the export features the vendor provides. With PostHog Cloud, you choose between two hosting regions, US (Virginia) and EU (Frankfurt), which is a meaningful decision if your data residency rules require EU storage. Self-hosting PostHog moves that decision into your own cloud account or data center, so the location, backups, encryption keys and network paths are set by your team. Confirm with your data protection officer whether the EU region meets your residency requirement, or whether your rules require storage in a specific country or on premises.
Identity and access controls are where the commercial and self-hosted options differ most in practice. PostHog's pricing page places SSO, audit logs, custom roles and project permissions in its platform packages, so on Cloud these controls are a paid decision. On a self-hosted instance, the features in the ee/ directory require a PostHog license, so ask PostHog exactly which of these controls your license covers before you design around them. Check whether your identity provider can enforce access to the PostHog instance without relying on those paid features, and document how you will handle joiners, movers and leavers for project access.
Compliance readiness is the work your team carries if you self-host. You own the evidence for access reviews, change records, backup and restore tests, log retention and encryption configuration, and you need to show how audit logs are kept and who can read them. PostHog's self-host documentation states that self-hosted deployments are officially unsupported and that PostHog does not offer customer support for product, infrastructure or other questions on self-hosted instances, so the operational responsibility sits with your team or your implementation partner. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or attestations. The auditor you engage decides whether your controls meet the requirements that apply to you.
What each option costs to own
Optimizely, PostHog Cloud and self-hosted PostHog bill for different things, so the comparison starts with which costs are contract-set, which are free up to a threshold and which fall on your own team. Use the supplied pricing pages for the public figures, and request everything else in writing before you compare totals.
Optimizely contract fees
Optimizely sells Feature Experimentation and Web Experimentation on custom plans billed on monthly active users, so the annual figure depends on the contract, the products bundled and the visitor volume you negotiate. Ask for the MAU definition in the order form, whether Web Experimentation counts every visitor on a page with the snippet, the renewal uplift and what happens to overage. No price is published here, so request a written quote for each product you need.
PostHog Cloud free tier
PostHog's pricing page states that the first 1 million analytics events are free every month, with 1 project and 1-year data retention on the Free plan. The Pay-as-you-go plan raises this to 6 projects and 7-year retention. SSO, audit logs, custom roles and project permissions are sold as platform packages, so ask for those package prices separately if you need them.
Self-hosted PostHog infrastructure
The hobby Docker Compose deployment is free under the MIT license, but you pay for the server, which PostHog's self-host documentation sizes at 4 vCPU, 16 GB of RAM and more than 30 GB of storage. Storage grows with event volume and retention, and the PostHog README says open-source deployments should scale to about 100k events per month before you move to Cloud. Price the server, block storage and egress for your own region.
Backups and storage operations
Backups, restore tests, disk growth monitoring and upgrades are recurring operational work that no free license covers. Plan for an off-host copy of the ClickHouse and PostgreSQL data, and budget internal time each month to test restores and apply upgrades. Ask your engineers to estimate these hours from your event volume, since PostHog does not supply a figure for your environment.
Paid support and internal staffing
PostHog states that self-hosted deployments are officially unsupported and that it does not offer customer support for product, infrastructure or other questions on self-hosted instances. Any production support has to come from your own engineers or from a third-party firm under a separate written scope. This is the largest cost that does not appear on either pricing page, and it recurs for as long as the platform runs.
One-time migration effort
Moving historical data is a one-time cost. PostHog's managed migrations import from Mixpanel or Amplitude, with each direct import job covering at most one year of data and events not deduplicated, and the documentation says historical imports need a paid product analytics plan to unlock the import features. Imported events cannot be selectively deleted, so cost the cleanup work before you start.
How a move from Optimizely to PostHog involves experiments and data
The sequence turns Optimizely experiments, flags and metrics into PostHog experiments and feature flags on a self-hosted instance, with a parallel run that shows whether results agree before traffic moves. Historical data is a separate decision, because PostHog's managed import does not read from Optimizely.
Inventory experiments, flags and metrics
Your product or experimentation owner lists every running and recent Optimizely experiment, feature flag, audience and primary metric, along with the page or code path each one touches. Engineering confirms which flags are still in use and which are stale. The output is a spreadsheet with one row per item, showing its owner, status, traffic allocation and the event that defines success. The inventory is done when every item has a named owner and a keep, rebuild or retire decision.
Decide which data to bring over
Decide which historical data is worth carrying into PostHog and which can stay in an Optimizely export or your warehouse. PostHog's managed migrations import historical events from Mixpanel or Amplitude, not Optimizely, so an Optimizely export needs its own load path. Each direct import job covers at most one year of data, events are not deduplicated, and once imported, event data cannot be selectively deleted. Confirm with your analytics lead and privacy owner which data sets are approved for import. The decision is recorded as a short list of approved sources and date ranges.
Size and deploy self-hosted PostHog
Engineering estimates monthly event volume from current Optimizely and analytics reporting, then chooses a deployment size. PostHog's self-host documentation describes a free Docker Compose hobby deployment under the MIT license, which it recommends for a server with 4 vCPU, 16 GB of RAM and more than 30 GB of storage. The PostHog README says open-source deployments should scale to about 100k events per month and recommends PostHog Cloud above that. Because self-hosted deployments are officially unsupported by PostHog, the team must own patching, backups and on-call. The step is done when a staging instance ingests test events and the team has a runbook for upgrades.
Rebuild experiments and flags in PostHog
Recreate each kept flag and experiment in PostHog's feature flags and experiments modules, using the same targeting rules, rollout percentages and primary metric definitions from the inventory. Metrics need to be defined against PostHog events, so any Optimizely metric that relied on a page view or a conversion event must be mapped to an equivalent event in your instrumentation. Swap the Optimizely SDK or snippet for the PostHog SDK in the affected code paths, and confirm that flag evaluations are stable for returning users. The step closes when a QA checklist passes for each rebuilt item in staging.
Run both platforms in parallel
Keep Optimizely and PostHog running side by side for a defined window agreed by the product and analytics owners, splitting traffic so each variant is measured in both systems where the design allows. Compare exposure counts, assignment consistency and metric values for the same experiments. Discrepancies are traced to instrumentation, bucketing or deduplication differences, since PostHog does not deduplicate imported events. The output is a reconciliation report signed off by the experiment owner. Do not treat parallel results as a statistical audit, and confirm the method with your analysts before relying on it.
Cut over and retire Optimizely
Move production traffic to PostHog flags and experiments in stages, starting with low-risk surfaces. Before the Optimizely contract ends, export configuration and results you need to keep, and store them in a location your records policy approves. Remove the Optimizely snippet and SDK calls from the codebase once no flag depends on them. Done means no production requests call Optimizely, the export archive is verified, and the access list for both systems has been reviewed and closed.
Questions buyers ask before switching from Optimizely
How much effort does a self-hosted PostHog deployment take to run?
Effort depends on the scale you need, the infrastructure you already operate and how many products you switch on. PostHog's self-host documentation recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage for the free Docker Compose (hobby) deployment, installed with a deploy-hobby script. The README says open-source deployments should scale to approximately 100k events per month, and recommends PostHog Cloud above that. Ongoing work includes patching, backups, storage growth, upgrades and monitoring, all carried by your team. Ask your engineers to estimate those hours against your real event volume before deciding.
Can a small team run self-hosted PostHog without outside help?
A small team can run the hobby deployment if it has someone comfortable with Docker, Linux operations and database maintenance. PostHog states that self-hosted deployments are officially unsupported and that it does not offer customer support for product, infrastructure or other questions on self-hosted instances, so fixes depend on your staff, the community and the source code. Teams that want a partner to plan, implement, harden, back up and document the deployment, or to provide ongoing support and upgrades on a retainer, can scope that work with DeployOpen in writing before any work starts.
How long does an Optimizely to PostHog migration take?
No fixed duration applies to every migration, and the timeline depends on what you are moving. The main drivers are how many events, properties and experiments you track, how many environments and teams depend on them, how much of your tracking code must change, and how much validation you require before cutover. PostHog's managed migrations cover importing historical events from Mixpanel or Amplitude, and each direct import job covers at most one year of data. Ask any implementation partner for a written schedule tied to a defined scope, and confirm the import limits for your source tool.
What does the migration need from our team?
A migration needs three things from your side: access, an event inventory and named owners. Access means credentials for Optimizely, your analytics sources, your hosting environment and your identity provider. The event inventory lists every tracked event, property, experiment, feature flag and metric, with a note on which dashboards and downstream systems use each one. Owners are product, analytics and engineering contacts who approve definitions and sign off on results. Teams with incomplete inventories usually spend the most time on rework, so start that list before choosing a timeline.
Can PostHog replace Optimizely's visual editor and web experiments?
Confirm this with the vendor before you decide, since PostHog's experiment features and its visual editing options change over time. PostHog's README groups feature flags and experiments within its product set, and its pricing page lists separate platform packages for SSO, audit logs, custom roles and project permissions. If your team relies on Optimizely's visual editor for marketing tests, check whether PostHog covers that workflow in the version you plan to run, or whether a separate tool is needed. Also check whether your experiments depend on Optimizely's stats engine, which will not carry over automatically.
What happens to our historical Optimizely data?
Historical experiment data does not move automatically, and you should plan the export before the contract changes. PostHog's managed migrations import historical events from Mixpanel or Amplitude using API credentials or JSONL files in an S3 bucket, and events are not deduplicated. PostHog's migration documentation also notes that there is no way to selectively delete event data once imported, so test imports on a copy of your data first. Export Optimizely results, configurations and raw event data as part of the inventory, and decide which historical records you must keep for audit or reporting.
When should we choose GrowthBook instead of PostHog?
Choose GrowthBook when experimentation is the main need and you want analysis to run against your own data warehouse. GrowthBook runs read-only SELECT queries against sources such as Snowflake, BigQuery and Postgres, and transmits only aggregated statistics. The free self-hosted Open Source plan allows 1 project with unlimited users and unlimited API requests, while the self-hosted Enterprise plan adds SSO and SCIM, approval workflows and holdouts. Choose PostHog when you want experiments tied directly to product analytics, session replay and feature flags in one tool. Compare both against your event volume, warehouse setup and stats requirements.
How DeployOpen helps you evaluate and move
DeployOpen plans, implements and supports self-hosted open-source platforms inside your own infrastructure, so an Optimizely vs PostHog evaluation can start from your actual experiment volume, data residency rules and analytics needs. We scope the work in writing before any build starts, and we prepare the controls and evidence your compliance reviewers will ask for.
How we scope
- We inventory your current Optimizely projects, experiments, metrics and monthly visitor volume before recommending a platform.
- We map which products you need in one place: experiments, product analytics, session replay and feature flags.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We deploy PostHog or GrowthBook in your cloud account, data center or air-gapped network, with the event pipeline sized to your traffic.
- We rebuild key experiments and funnels, and we check that results match the Optimizely events export before cutover.
- We test authentication, data access roles and event collection, and we document any gaps against the features you use.
How we hand over
- You receive architecture diagrams, runbooks for backups, upgrades and scaling, and a written record of what was migrated.
- We document which PostHog features sit under the ee directory license and which need a paid plan or license.
- We walk your engineering and product teams through running experiments, reviewing results and rolling back a flag.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, which matters because self-hosted PostHog is not supported by its vendor.
- We can plan upgrades and capacity reviews as your event volume grows past the free deployment's intended scale.
- We prepare systems and evidence for compliance assessments, while independent auditors and certification bodies issue any reports.
