Statsig vs PostHog: which fits your team if you use Statsig for all three jobs
If one Statsig contract covers your feature flags, experiments and product analytics, PostHog fits teams that want one self-hosted tool for all three jobs and can run it without vendor support. GrowthBook plus a separate analytics tool fits teams that want experiment statistics tied directly to their warehouse. Both answers depend on what you need from the renewal, the ownership change and your data residency rules, so start by naming which of those is driving the move.
PostHog covers the same ground in one product: feature flags, experiments and product analytics sit alongside each other, so event data, flag exposures and funnels share one store. The free self-hosted path is a Docker Compose hobby deployment under the MIT license, and the PostHog README says open-source deployments should scale to about 100k events per month before moving to PostHog Cloud. PostHog's self-host documentation also states that self-hosted instances are officially unsupported, with no customer support for product or infrastructure questions. Confirm whether your organization can carry that operating risk, and check which premium features sit in the ee/ directory under a separate license before you depend on them.
The decision turns on four drivers: your monthly event volume against the free self-hosted ceiling, whether you need a vendor to answer for production incidents, whether your analytics data must stay in a warehouse you already own, and how much multi-service operations your team will accept. If volume is modest, you need no vendor support, and you want one tool, PostHog is the shorter path. If you need warehouse-native statistics or vendor support for experiments, pair self-hosted GrowthBook with the analytics tool you already trust and budget for the warehouse queries it runs.
Which option fits which scenario
This table maps common Statsig replacement scenarios to the better fit between self-hosted PostHog and a self-hosted GrowthBook plus a separate analytics tool. Read each row against your own event volume, support requirements and warehouse setup, since the reasons rely on the licensing, scale and support limits documented for PostHog.
| Scenario | Better fit | Reason |
|---|---|---|
| One self-hosted tool for flags, experiments and analytics | Self-hosted PostHog | PostHog's README groups feature flags, experiments and product analytics in one product, so one deployment covers all three jobs. |
| Event volume near the open-source ceiling | GrowthBook plus a separate analytics tool | PostHog's README says open-source deployments should scale to about 100k events per month and recommends PostHog Cloud above that. |
| Need for a contracted vendor support party | Neither self-hosted option alone | PostHog states self-hosted deployments are unsupported. Confirm support terms with each vendor or a contracted partner before deciding. |
| Warehouse-native experiment analysis | GrowthBook | GrowthBook runs read-only SELECT queries against your warehouse and returns only aggregated statistics, which keeps event data in place. |
| Team already running a data warehouse | GrowthBook, with analytics in the warehouse | GrowthBook connects to sources such as Snowflake, BigQuery and Postgres, so existing warehouse data can feed experiments without a second event store. |
| Regulated environment needing a contracted support party | Confirm with both vendors and a partner | Because self-hosted PostHog has no vendor customer support, assess which party will sign support terms and accept responsibility for your environment before choosing. |
How data location and hosting differ
Statsig is a hosted service, so the vendor operates the application, the event pipeline and the storage that holds gates, experiments and analytics events. Warehouse native deployment is offered as an Enterprise option, which keeps the event data in your own warehouse while the Statsig control plane still runs in the vendor's environment. Whether that split satisfies your data residency or sub-processor requirements depends on the contract, not on the product page alone.
- Data custody: Hosted events and analytics sit in vendor-operated storage unless warehouse native is contracted and configured.
- Shared responsibility: The vendor patches and runs the platform, but your team owns the SDK integration, access reviews and the keys given to the service.
- Identity and access: SSO, SCIM and audit controls are tied to the plan tier, so confirm which of them your contract includes before relying on them for access reviews.
- Compliance evidence: Ask for the vendor's current audit reports, its sub-processor list and any HIPAA business associate agreement, and check that each one covers the product tier you buy.
- Ownership change: Confirm with the vendor how data processing terms carry over after the acquisitions described in the Statsig pillar, since contract counterparties may change.
Before signing, ask in writing where each data type is stored, which regions are used, and whether warehouse native changes the processing terms for your use case.
Self-hosted PostHog keeps event data on infrastructure you operate, so the data location is set by your own network and storage choices. The MIT-licensed core is open, but the repository states that premium features in the ee directory need a PostHog license on a self-hosted instance. Your team also carries the operational load that the vendor carries in its own cloud, and PostHog's documentation states that self-hosted deployments are officially unsupported.
- Data custody: Events, session data and analytics stay in databases and object storage you control, which simplifies residency arguments for regulated data.
- Licensing boundary: Confirm which features you use sit outside the ee directory, or buy the license that covers them, before you assume the whole stack is free.
- Support boundary: PostHog does not provide customer support for self-hosted product or infrastructure questions, so incident response, upgrades and backups fall to your team or a partner you contract separately.
- Compliance evidence: Controls such as access logging, encryption at rest and backup testing become your evidence to produce for an auditor, since no vendor report covers your instance.
- Scale limits: The README says open-source deployments should scale to about 100k events per month and recommends PostHog Cloud above that, so check your volume against this before choosing self-hosting for compliance reasons.
Confirm the license terms for each module you plan to run and write down who on your side owns the on-call and patching duties.
Self-hosted GrowthBook sends experiment analysis to the data source you already run, such as Snowflake, BigQuery or Postgres, and it runs only SELECT queries there, returning aggregated statistics to the application. Feature flag metadata lives in MongoDB or a compatible database that you host. The result is that user-level event data stays in your warehouse under your existing access controls, while GrowthBook itself handles flags and statistics.
- Data custody: Experiment data remains in the warehouse, and only aggregates travel back to the GrowthBook application.
- Licensing boundary: The LICENSE file places code outside the enterprise directories under MIT, and features such as SSO and SCIM are in the separately licensed enterprise directories.
- Operations scope: Your team runs the Docker image or Helm chart, the MongoDB store, file storage and backups, and it owns the database credentials it grants to GrowthBook.
- Compliance evidence: Access to the warehouse, query logs and the flag store become your records, so align them with your existing warehouse audit trail.
- Warehouse cost: Experiment queries consume compute in your warehouse, which is a cost that depends on query volume and metric count rather than on a GrowthBook invoice.
Confirm that your warehouse team accepts a dedicated read-only role for GrowthBook and that your compliance scope covers the MongoDB store.
Where free self-hosted PostHog reaches its limits
The free self-hosted path to PostHog is a Docker Compose hobby deployment, released under the MIT license and installed with a deploy-hobby script. PostHog's self-host documentation recommends a server with the equivalent of 4 vCPU, 16 GB of RAM and more than 30 GB of storage. Treat that as a floor for a small test, not a sizing for production traffic. The README says open-source deployments should scale to roughly 100k events per month and recommends moving to PostHog Cloud above that. Before you commit, estimate your monthly event volume across web, mobile and backend sources, since the three jobs of flags, experiments and analytics all draw on the same event stream. Also note that new Kubernetes deployments of the paid self-hosted product are no longer supported, so a Helm-based design that you planned for a larger footprint is not an option on that path.
The licensing boundary matters as much as the scale limit. The PostHog repository is MIT licensed, but the ee/ directory is covered by a separate license in ee/LICENSE. The README states that premium features from ee/ on a self-hosted instance require a PostHog license. Read the PostHog LICENSE file and map each feature you rely on to its directory before you build on it. If your policy requires fully free software, the README points to the posthog-foss repository, which is purged of all proprietary code and features. Confirm with PostHog which features you would lose on that fork, especially any flag or experiment capability your team uses today.
Finally, self-hosted PostHog is officially unsupported, and PostHog does not provide customer support for product, infrastructure or other questions on self-hosted instances. Upgrades, backups, scaling and incident response therefore sit with your own team or your implementation partner. Put that ownership into the decision: name who patches the stack, who restores it and who answers when event ingestion stalls. If the volume or licensing analysis points beyond the free path, compare the paid self-hosted terms, PostHog Cloud regions and any platform package you would need against the commitments you are prepared to carry in-house.
What no vendor support means for a self-hosted PostHog team
Choosing self-hosted PostHog for flags, experiments and analytics moves the support boundary inside your organization. The cards below cover what PostHog documents about self-hosted support and what your team then owns, from upgrades and backups to incident response and staffing.
Self-hosted deployments are unsupported
PostHog's self-host documentation states that self-hosted deployments are officially unsupported. That is a documented position, not a contract term you can negotiate away on the free path. Before you commit, read the self-host documentation and record in your architecture decision which parts of the stack you accept as unsupported by the vendor.
No product or infrastructure help
PostHog does not offer customer support for product, infrastructure or other questions on self-hosted instances. A question about a flag evaluation, an experiment readout or a ClickHouse disk problem goes to your own engineers or to a partner you have engaged in writing. Ask who in your organization answers those questions before launch, not during an outage.
Upgrades, backups and scaling in-house
Your team schedules upgrades, tests them against your flags and experiments, and backs up the databases that hold events and configuration. Scaling is also yours to plan. PostHog's README says open-source deployments should scale to approximately 100k events per month and recommends its cloud product above that, so growth in event volume is the trigger to re-check the decision.
Incident response without a vendor
When flag evaluation or event ingestion fails, no vendor engineer joins the bridge call. Your runbook must cover who is paged, how a feature flag is rolled back by hand if the service is down, and how application code behaves when PostHog is unreachable. Test that fallback path before a release depends on it.
Staffing the maintainers
The stack needs people who understand Docker Compose or Kubernetes, the database layer and the PostHog release notes. Name at least two maintainers and confirm they have time for upgrades. If the only person who understands the deployment leaves, the flag platform becomes a single point of failure for product launches.
Partner support under written scope
An implementation partner can take on installation, hardening, backup design, upgrade runs and on-call support, but only the activities named in a signed scope are covered. Ask for the deliverables, response expectations and handover documentation in writing. Keep the vendor documentation, your runbooks and the partner scope together so auditors and procurement see one ownership model.
When GrowthBook plus a separate analytics tool is the better split
Choose a GrowthBook plus separate analytics split when your statistics and event data already live in a warehouse you control and your team wants experiment analysis to run against that warehouse. GrowthBook analyzes experiments by running only SELECT queries against your own data source, such as Snowflake, BigQuery, Postgres or Trino, and it sends back only aggregated statistics. Event data stays where it is, and the analytics tool is simply one more upstream feed into that warehouse. This split suits teams that already pay for warehouse compute and want one copy of experiment metrics rather than a second event store inside an experimentation product.
Start with the self-hosted limits, because they shape the design. The free self-hosted Open Source plan allows 1 project, unlimited users and unlimited API requests, so a single-product organization can run it without seat fees. SSO and SCIM, advanced permissioning, approval workflows, safe rollouts, holdouts and sticky bucketing sit in the self-hosted Enterprise tier. Confirm with GrowthBook which of these your identity and change control requirements need. The GrowthBook code outside its enterprise directories is MIT licensed, but the enterprise directories fall under a separate license, so legal review should cover the exact modules you deploy.
The added integration work is real and recurring, so budget for it explicitly. Your team must maintain the warehouse pipeline that carries events from the analytics tool or SDKs into tables GrowthBook can query, define metric SQL, and switch application code from the Statsig or PostHog SDK to a GrowthBook SDK, which the LaunchDarkly importer documentation also notes is a separate step after any import. Ask any implementation partner to scope the pipeline, metric definitions and query cost monitoring in writing before you commit.
How a move from Statsig to PostHog or GrowthBook plus analytics runs
The sequence produces a documented inventory, a chosen target split, a parallel run that proves flag evaluation and experiment results match, and a Statsig shutdown with nothing lost that you still need.
Inventory flags, experiments, metrics and events
Your engineering lead and a product analyst list every feature gate, dynamic config, experiment, segment, metric definition and analytics event that Statsig holds, and note which application services call each one. Record the owner, the environment and whether the item is still active. Confirm with Statsig which objects you can export through its Console API, since that is the export path for anything PostHog's managed migrations do not cover. The inventory is done when each item has an owner and a keep, rebuild or retire decision.
Decide the target split
Decide whether PostHog alone covers flags, experiments and product analytics, or whether GrowthBook handles flags and experiments while a separate analytics tool handles events. Check PostHog's self-hosted limits against your event volume, since its README says open-source deployments should scale to approximately 100k events per month and points larger workloads to PostHog Cloud. Confirm with PostHog that the self-hosted edition you plan to run includes the features you need, because premium features in the ee directory need a PostHog license. The decision is recorded with the reason for each job.
Stand up the chosen platform
Your platform team deploys the target inside your own infrastructure. For PostHog, the hobby Docker Compose deployment is installed with a deploy-hobby script and documented as unsupported for self-hosted instances, so your team owns patching, backups and incident response. For GrowthBook, the team deploys the single Docker image or official Helm chart and provides a MongoDB or compatible database, with a managed service suggested for production. The platform is ready when test projects run, users can sign in and the backup and restore procedure has been tested once.
Map SDK calls and flag evaluation
Developers map each Statsig SDK call, including gate checks, dynamic config reads and experiment assignments, to the target SDK. Where you want to keep application code independent of one vendor, use OpenFeature providers as the translation layer. Verify that targeting, rollout percentages and user identifiers produce the same result for the same user in both systems, using a fixed test set of users. Confirm this with the flag owners in writing. The step closes when every mapped call passes the test set in a non-production environment.
Migrate historical data where supported
Move configuration and history according to what each tool can import. PostHog's managed migrations import historical events from Mixpanel or Amplitude, not from Statsig, so Statsig event history needs an export path through your warehouse or a custom script. PostHog direct import jobs cover at most one year of data per job, events are not deduplicated, and imported data cannot be selectively deleted, so test a small import first and agree the deduplication approach beforehand. Historical imports are free of ingestion fees when sent with the historical_migration flag, but a paid product analytics plan is required to unlock the import features. Record what was imported, what was not and why.
Run dual-write or parallel evaluation
Run Statsig and the target side by side. Either send analytics events to both systems or evaluate flags in both and log the results without changing user experience. Compare exposure counts, assignment splits and key metric values over the same period, and investigate every mismatch with the owner of the flag or metric. Your analyst signs off when differences are explained, not when they are zero, because the two tools may define events and sessions differently. Keep the parallel run until the agreed sign-off criteria are met.
Cut over
Switch production traffic to the target one flag or experiment group at a time, starting with low-risk items and keeping a documented rollback to Statsig for each. Monitor error rates, flag evaluation latency and experiment exposure logs during each switch. Product and engineering owners confirm each cut in the change record. The cutover is complete when no production code path calls Statsig for flags or experiments and every rollback path has been retired or deliberately kept.
Retire Statsig
Export final copies of configurations, experiment results and metric definitions, store them under your retention policy, and confirm with Statsig and your contract owner how data deletion will be handled and documented. Remove Statsig SDKs, keys and webhooks from code and pipelines, then revoke API credentials. Retirement is done when the export archive is verified, the deletion confirmation is on file and the Statsig account has no active integrations.
Questions buyers ask before choosing a self-hosted option
Can one self-hosted tool replace Statsig's flags, experiments and analytics?
PostHog covers all three jobs in one product: its README groups feature flags, experiments and product analytics under the same platform, so one deployment can serve them. The trade-off is depth and scope. Confirm that the experiment statistics, flag targeting and analytics queries your teams rely on today are available in the version you plan to run, and test them against a representative set of your existing experiments before you decide. Teams that need warehouse-native analysis of data they already keep in Snowflake or BigQuery may prefer a split design, which is covered on this page.
What drives the cost of self-hosting PostHog, and what recurs?
Costs fall into three groups: the server, the people who operate it, and the change work to move. PostHog's self-host documentation recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage for its hobby deployment, so compute and storage recur every month. Storage and retention grow with event volume. Operations staff time recurs for upgrades, backups and monitoring. Setup, data mapping and SDK changes are largely one-time. Ask any partner to price each group separately so you can see which costs grow with your usage.
How long does a migration take, and what does it depend on?
Duration depends on how many flags, experiments and event sources you run, how many SDK calls sit in your code, and how much historical data you need to keep. No duration is published for this migration, so treat any figure you receive as an estimate to test. Historical import is limited: PostHog's managed migrations cover at most one year of data per direct import job, and events are not deduplicated. Plan for a parallel run where both systems receive events so you can compare results before cutting over.
Can our own engineers run the migration without an outside party?
Yes, if you have engineers who know your Statsig SDK usage, your event schema and your experiment process. PostHog's self-host documentation states that self-hosted deployments are officially unsupported and that PostHog provides no customer support for product, infrastructure or other questions on self-hosted instances. That means your team owns troubleshooting, upgrades and incident response. Ask yourself whether you have on-call coverage and a tested restore process before you move production traffic onto the platform.
What do we need to provide from our side?
You need named owners for each area: infrastructure, data, product analytics, experiment design and security. Infrastructure must host the server, a database and backups in your own environment. Data owners must confirm which events, properties and users may be sent to the new system and how long they may be kept. Product and engineering teams must agree which SDK calls change. Security reviewers should review access controls, the hosting region and the licence terms for any features in the ee directory, since premium features on self-hosted instances require a PostHog license.
Does PostHog's free tier cover our event volume?
It depends on your monthly event count and on whether you choose the cloud service or self-hosting. PostHog's pricing page states that the first 1 million analytics events are free every month on its cloud plans, and the Free plan includes 1 project and 1-year data retention. The README says open-source deployments should scale to approximately 100k events per month and recommends migrating to PostHog Cloud above that. Measure your current monthly events from Statsig's usage reports before comparing, because the free self-hosted tier and the free cloud tier have different limits.
What should we ask a vendor or partner in a written quote?
Ask for a fixed scope that lists every component, deliverable and exclusion, including flag migration, experiment re-creation, analytics dashboards, SDK refactoring, testing, cutover and handover. Request separate line items for one-time work and recurring support, upgrades and backups. Ask how historical data will be handled, what happens if a migration step fails, and who is responsible for licence checks on enterprise features. Confirm the acceptance criteria in writing. DeployOpen plans and implements self-hosted platforms inside your own infrastructure and works from fixed, written scopes, so ask for the scope in that form.
What to confirm before you commit to a split
Start with the PostHog license, because it decides whether a self-hosted PostHog covers your needs at all. The repository is MIT Expat licensed except for the ee/ directory, and the README says premium features from that directory on a self-hosted instance require a PostHog license. List the exact features you need, such as feature flags, experiments, SSO, audit logs or custom roles, then confirm in writing with PostHog which of them sit under ee/ and what license terms apply to them today. Also confirm whether you need the posthog-foss repository instead, since it contains no proprietary code. Ask PostHog directly what support, if any, it provides for a self-hosted instance, because its self-host documentation says self-hosted deployments are officially unsupported.
Next, confirm the Statsig terms as they stand after the ownership changes. Statsig announced on September 2, 2025 that it would join OpenAI, and its blog states that Amplitude acquired Statsig on May 5, 2026. Ask your account team in writing whether pricing, data retention, data processing terms, warehouse native deployment and support commitments will change at renewal, and which contract clauses cover assignment or change of control. Then measure your own event volume for the last twelve months, split by product analytics, experiments and flag evaluations. PostHog's README says open-source deployments should scale to approximately 100k events per month and recommends PostHog Cloud above that, so volume is the first number that decides between self-hosting and a managed plan.
Finally, check the parts of the decision that sit inside your own organization. Confirm whether your data warehouse can serve experiment queries, since GrowthBook needs a connected source and Statsig keeps warehouse native deployment on its Enterprise plan. Estimate the people who will patch, back up and upgrade PostHog and its data store, and who will answer product questions without vendor support. Map your compliance obligations, including where event data may be stored and which safeguards you must evidence, and check whether any of them restricts a hosted product analytics service. Once these answers are written down, price each option from a written scope rather than from list prices, and ask any implementation partner to quote the components separately.
How DeployOpen helps you evaluate, implement or migrate
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Statsig vs PostHog, we start with a written scope that separates the flag, experiment and analytics jobs so you can decide which tools go where before any work begins.
How we scope
- Map which Statsig gates, experiments and analytics dashboards your teams actually use today
- Decide whether PostHog's free self-hosted tier covers your event volume or whether a split design is needed
- Agree deliverables, timelines and responsibilities in writing before any build work starts
How we build
- Deploy the chosen self-hosted platforms in your environment, using the hosting method your security team approves
- Configure flags, experiments and event pipelines, and test them against representative traffic and data
- Run security testing on the deployed platforms and their integrations before they carry production traffic
How we hand over
- Document architecture, configuration, access roles and the data flows between flags, events and warehouse
- Provide runbooks for upgrades, backups and restores, and the migration steps for each Statsig object
- Prepare control and evidence material for your compliance team, noting that auditors issue any assessment
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Retainers can cover self-hosted PostHog or GrowthBook operations, since PostHog does not offer vendor support for self-hosted instances
- Ask us to confirm support scope, response expectations and upgrade coverage in the written quote
