When to choose Mixpanel vs PostHog for event analytics
Choose PostHog when the trigger is a Mixpanel renewal, a data residency requirement that a self-hosted or EU-hosted deployment must meet, or a licensing change you cannot accept for core analytics. Mixpanel fits teams whose main need is event reports, funnels and cohorts in a managed service and who are content with its hosting model and plan terms. PostHog covers the same event analytics and adds session replay, feature flags, experiments and surveys in one product, and its MIT-licensed core can run on your own servers. Confirm the exact tier that includes each feature you need, since the free core, the self-hosted core and the paid features in the ee directory differ.
Three questions usually settle the decision. First, how long must event history stay queryable: check Mixpanel's current default retention in your contract against PostHog Cloud's plan-based retention on the PostHog pricing page, and remember that imported history is limited to one year per direct import job. Second, do session replay and flags matter to the same team, because adding them to Mixpanel means a second vendor and a second data flow. Third, where must the data sit: PostHog Cloud offers US and EU regions, while a self-hosted deployment keeps data in your own infrastructure.
The last factor is operating capacity. PostHog's self-hosted deployments are officially unsupported and PostHog does not provide customer support for them, so the team running the stack carries upgrades, backups, scaling and incident response, or a partner such as DeployOpen covers those under a written scope. If you cannot staff that work, PostHog Cloud or Mixpanel is the more honest choice. Confirm your expected monthly event volume early, because the project's own guidance points open-source deployments toward Cloud at larger volumes.
Which product fits each buying scenario
This table pairs common buying situations with the platform that fits better and the condition that decides it. Read each row against your own event volume, retention needs, residency rules and in-house platform capacity, because the right answer shifts with those conditions. The main takeaway is that PostHog covers more product areas, but self-hosting it moves operational ownership onto your team.
| Scenario | Better fit | Condition that decides it |
|---|---|---|
| Small team using only event analytics | Mixpanel or PostHog Cloud | Compare event volume and the free tier limits on PostHog's pricing page with your Mixpanel plan, then pick the one that matches your reporting needs |
| Team needs session replay, flags and experiments with analytics | PostHog | PostHog's README lists session replay, feature flags, experiments and surveys alongside product analytics, so one tool covers the set |
| Strict data residency in the EU | PostHog Cloud EU (Frankfurt) or self-hosted PostHog | PostHog Cloud offers an EU region. Confirm with Mixpanel which regional endpoint and residency terms apply to your account |
| Need a fully self-hosted deployment with no vendor-run cloud | Self-hosted PostHog, with planning | Core code is MIT licensed, but premium features in the ee directory need a PostHog license, and self-hosted deployments are officially unsupported |
| Team with no platform engineers | Mixpanel or PostHog Cloud | PostHog states it does not offer customer support for self-hosted instances, so someone must own upgrades, storage and uptime |
| Long-term retention of raw event history | PostHog Cloud on a paid plan, or Mixpanel | PostHog's Free plan keeps data for 1 year and Pay-as-you-go for 7 years. Check Mixpanel's default retention against your audit needs |
| Migrating existing Mixpanel history | PostHog | PostHog's managed migration imports Mixpanel history in jobs of at most one year, and a paid product analytics plan is required for import features |
| Event volume well beyond 100k per month on a self-hosted install | PostHog Cloud | PostHog's README says open-source deployments should scale to about 100k events per month and recommends Cloud above that |
How Mixpanel's default retention and PostHog's plan retention change your history
Decide your history window before you choose a PostHog plan, because retention sets how far back your product analytics can look. Mixpanel's default retention is 2 years, so many teams never check the limit. On PostHog Cloud, the Free plan keeps data for 1 year, and the Pay-as-you-go plan keeps it for 7 years. A year-over-year trend, a cohort built on a signup from 18 months ago, or an audit question about last year's onboarding flow can fail on the Free plan. Confirm your current Mixpanel retention setting, then list the reports, cohorts and audit questions that need more than 12 months of events. Check the current limits on the PostHog pricing page before you commit to a plan.
PostHog's managed migration from Mixpanel cannot close that gap in one step. A direct import covers at most one year of data per job, and events are not deduplicated, so overlapping date windows will double-count. For a multi-year history, plan one job per non-overlapping window and write down each start and end date before the first run. Validate each window by comparing event counts for a sample day or week in Mixpanel's reports against the same period in PostHog, and record who ran each job. Historical imports also require a paid product analytics plan to unlock the import features, so confirm that subscription before the migration begins. The managed migrations documentation describes the job parameters.
Once events are imported, there is no way to selectively delete them in PostHog, so a wrong date window or a mis-mapped property stays in the project. Run one window in a non-production project first, and run the full history only after that test matches your Mixpanel counts. Keep the source of record outside PostHog: retain your Mixpanel project until finance and analytics sign off on the numbers, and export raw events for any period an auditor may ask about. Cohorts built on historical behavior are only as complete as the imported window, so document which dates each cohort depends on. Ask PostHog to confirm in writing how its retention limits apply to imported events on the plan you choose.
Where Mixpanel and PostHog differ in features, and where they match
This table compares the event analytics both products offer with the wider PostHog product set and its licensing split. Rows marked as points to confirm need a vendor answer before you rely on them. The main takeaway is that the core event analytics overlap, while PostHog adds replay, flags, experiments and surveys and can be self-hosted under an open-source core.
| Capability | Mixpanel | PostHog |
|---|---|---|
| Reports, cohorts and funnels | Offered as core event analytics | Offered in product analytics; confirm report-level parity for your queries |
| Session replay | Confirm availability and plan terms with Mixpanel | Included as a product alongside analytics |
| Feature flags and experiments | Confirm whether native support exists and its limits | Included as a product under feature flags and experiments |
| Surveys and error tracking | Confirm with Mixpanel before assuming coverage | Surveys and error tracking listed among PostHog products |
| Data pipelines | Export through the Raw Event Export API; confirm scope | Data pipelines listed as a PostHog product |
| License and source | Commercial hosted service; confirm terms and any self-hosting option | MIT core; the ee directory needs a license for premium self-hosted features |
| Fully open-source edition | Not applicable | posthog-foss repository is purged of all proprietary code and features |
| Default data retention | Two-year default, per the reference supplied for this page | Free plan one year; Pay-as-you-go seven years on PostHog Cloud |
| Hosting regions | Confirm EU and other regional endpoints with Mixpanel | US (Virginia) and EU (Frankfurt) Cloud regions; self-hosting keeps data on your servers |
What data location and hosting options mean for compliance
Data location is usually the first question in a Mixpanel renewal review, and it shapes everything after it. The options below are separate decisions: which PostHog Cloud region to use, whether to self-host, what Mixpanel's own regional endpoints mean for your current data, which paid platform features you need, and how transfer rules apply. DeployOpen prepares the technical controls and evidence for your assessors, but the compliance conclusion stays with your counsel and auditors.
PostHog Cloud regions
PostHog Cloud offers two hosting regions, US (Virginia) and EU (Frankfurt). Choosing the region is a decision to make before the first event is sent, because moving existing history between regions is not a simple switch. Confirm which region your project is provisioned in, where session replay recordings and any exports are stored, and which sub-processors PostHog uses in each region. Ask PostHog for its current data processing terms and subprocessor list, and record the answers for your records of processing.
Self-hosting in your own infrastructure
Self-hosting keeps event data inside your cloud accounts or data centers, so residency is set by your own architecture rather than by a vendor region. The cost is operational: you own patching, backups, scaling and incident response for the stack. PostHog's self-host documentation states that self-hosted deployments are officially unsupported, so your team or a partner such as DeployOpen must carry that support load. Document where the database, object storage and backups sit, and who holds administrative access.
Mixpanel regional endpoints
Mixpanel offers regional endpoints, including ones used for EU and India residency, which determine where your event data is processed and stored. Before you decide, confirm which region your Mixpanel project uses today, since that determines where your historical data sits and where any export must be pulled from. Ask Mixpanel to confirm the residency of data held in the project, its subprocessors, and whether backups or derived reports follow the same region. Your export and migration plan should start from that confirmed answer.
SSO and audit logs as platform packages
PostHog's pricing page says SSO, audit logs, custom roles and project permissions are sold as platform packages rather than included in every plan. Access control and audit trails are often the evidence assessors ask for first, so the cost of these features belongs in the same comparison as hosting. Check whether your identity provider integration, role model and audit log retention requirements are met by the package you would buy, or by controls you build yourself in a self-hosted deployment.
EU-US Data Privacy Framework as one input
The European Commission adopted its adequacy decision for the EU-US Data Privacy Framework on July 10, 2023 (decision 2023/1795), which allows personal data to flow from the EU to US companies that participate in the framework. Whether a US-hosted PostHog Cloud project relies on that decision, or on other transfer mechanisms, is a question to confirm with the vendor. Participation is one input to your transfer impact assessment, alongside the data categories, access patterns and supplementary measures you document. DeployOpen can prepare the technical evidence for that assessment, but it does not issue legal conclusions.
What running PostHog yourself involves
PostHog Cloud is the hosted option, where PostHog operates the infrastructure and you send events to a managed project. You choose between two hosting regions, US (Virginia) and EU (Frankfurt), which is the main residency decision for this option. The first 1 million analytics events each month are free, and the Free plan includes 1 project and 1-year data retention. The Pay-as-you-go plan raises this to 6 projects and 7-year data retention. SSO, audit logs, custom roles and project permissions are sold as platform packages, so check those against your access control requirements.
- Operations: PostHog runs the servers, upgrades and scaling, so your team does not maintain a database or ingestion tier.
- Regions: Choose US (Virginia) or EU (Frankfurt) at setup and confirm where session replay and exports are stored.
- Retention: Retention depends on the plan, so map your required history length to the Free or Pay-as-you-go limits.
- Identity features: SSO, audit logs and custom roles are platform packages, so ask for their price in writing.
- Support: Cloud accounts receive vendor support, which is the main difference from the self-managed options.
Confirm the regional hosting choice, the plan retention, and which platform packages your governance team needs before you commit to this option.
The hobby deployment is a free, MIT-licensed Docker Compose setup that you install on your own server with a deploy-hobby script. It suits evaluation, internal testing and small workloads. PostHog recommends a server with the equivalent of 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 moving to PostHog Cloud above that level. Your team carries every operational task, including backups, upgrades, TLS, storage growth and monitoring.
- Installation: The deploy-hobby script sets up the Docker Compose stack on a single host.
- Sizing: Plan for the recommended 4 vCPU, 16 GB of RAM and more than 30 GB of storage as a starting point.
- Volume ceiling: PostHog suggests about 100k events per month before moving to Cloud.
- Support: Self-hosted instances are officially unsupported, and PostHog offers no customer support for product, infrastructure or other questions.
- Ownership: Your engineers handle backups, upgrades, security patches and incident response.
Confirm your expected monthly event volume against the 100k guidance, and name an internal owner for upgrades and backups before you install.
The paid self-hosted product runs the code in the ee directory, which needs a PostHog license for premium features on your own instance. It is for organizations that need to keep data inside their own network while using licensed capabilities. PostHog no longer supports new Kubernetes deployments of this paid self-hosted product, so plan the target platform with that limit in mind. Self-hosted instances carry the same unsupported status as the hobby setup, so the vendor relationship does not replace your internal operations or a third-party support arrangement.
- Licensing: Premium features in the ee directory require a PostHog license, which is a separate purchase from the MIT code.
- Kubernetes: New Kubernetes deployments of the paid self-hosted product are no longer supported, so confirm the deployment target before design work starts.
- Support boundary: PostHog does not provide customer support for self-hosted instances, so incidents rest with your team or your implementation partner.
- Operating cost: Infrastructure, staff time for upgrades and monitoring, and license fees recur, while setup work is largely one-time.
- Scope of the free code: The posthog-foss repository is purged of proprietary code and features, which matters if you need only open-source components.
Ask PostHog in writing which features the license covers, whether your target platform is supported, and who responds to incidents on your self-hosted instance.
What drives the Mixpanel vs PostHog cost curve as event volume grows
The cost curve for Mixpanel against PostHog bends at different points, so the decision depends on where your event volume will sit in 12 to 36 months, not on today's invoice. On the Mixpanel side, you pay Mixpanel for its plan and event tier, and costs rise as monthly events climb. Ask Mixpanel for a written quote that states the tier, the event allowance, overage rates, the retention period and which features (such as the Raw Event Export API) are included or extra. On the PostHog Cloud side, the first 1 million analytics events are free each month, according to PostHog's pricing page, and usage above that is billed on the plan you choose. Ask PostHog for a quote that shows how each product, plan and volume band is charged, and confirm whether session replay, flags or surveys are billed separately from event analytics.
A self-hosted PostHog moves the cost from a vendor invoice to your own infrastructure and staff. The self-host documentation recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage for a hobby deployment, and the README says open-source deployments should scale to approximately 100k events per month before PostHog Cloud is recommended. Recurring costs include compute and storage that grow with event volume, backups, upgrades, monitoring, and the engineering time to run them. PostHog states that self-hosted deployments are officially unsupported, so the staff hours and any paid external help are your cost to plan. One-time costs include the historical import and the SDK swap. PostHog's managed migrations need a paid product analytics plan to unlock import features, and each direct import job covers at most one year of data, so a multi-year history multiplies that work. Confirm the import plan and the number of jobs with PostHog before you budget.
Before you compare totals, get two inputs in writing: a month-by-month event volume projection for each product, including growth from new features and new regions, and a list of the event properties you will keep. Event volume is the main driver on both sides, so a projection built from current traffic will understate the cost curve for a fast-growing product. Then ask each vendor to price the same projection over the same period, and ask your own team to estimate the recurring operating hours for a self-hosted deployment. Any figure you put on a self-hosted line should come from your own environment and your own staff rates, not from a benchmark.
How a move from Mixpanel to PostHog runs, step by step
This sequence takes your Mixpanel events, dashboards and identities into PostHog with a documented record of what was imported, what was mapped and which reports still agree before anyone switches off the old data.
Inventory events, properties and dashboards
Your product or analytics lead lists every tracked event, its key properties, the cohorts and funnels that depend on them, and the dashboards people actually open. Keep the list in a shared spreadsheet with an owner for each row. Done means every dashboard has a named report it depends on and every event has a yes or no for migration. Anything nobody can explain is a candidate for retirement rather than import.
Decide the retention and hosting target
Before importing anything, decide where the data will live and how long you need it. PostHog Cloud is offered in US (Virginia) and EU (Frankfurt) regions, and its plans set different data retention periods, so check the current figures on the pricing page against your residency and reporting needs. A self-hosted PostHog deployment is the other option, and it carries its own operating responsibilities. The output is a short written decision that names the region or host, the retention you need and who approved it.
Confirm the plan that unlocks import features
PostHog's migration documentation says 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. Ask your PostHog contact or check the pricing page to confirm which plan applies to your project before you schedule any job. The output is a confirmed plan on the target project, recorded in the migration ticket.
Run the managed import in one-year jobs
Using a Mixpanel service account or project secret, create a managed migration in PostHog that pulls historical events directly from Mixpanel. Each direct import job covers at most one year of data, so a multi-year history runs as a sequence of jobs, one per year. Events are not deduplicated, so do not re-run a window that already completed without first removing the earlier data plan. Record the job name, the date window and the event count for each run. Alternatively, export raw events from Mixpanel as JSONL and load them from an S3 bucket.
Map event and property names
Imported events keep their Mixpanel names unless you map them, so decide which names move as-is and which need renaming for consistency with new PostHog instrumentation. Write the mapping as a table with the old name, new name, property changes and a note on any property that changes type. Have an analyst run a sample query for each renamed event in both systems. The output is a signed-off mapping file that the import and the new SDK both follow.
Preserve user and group identities
Confirm how Mixpanel distinct IDs and any alias or identify calls map to PostHog person records, so that a returning user is not split into two profiles across the cutover. Test this with a small set of known accounts and check that their history appears under one person. Document any identities that cannot be merged. The output is a short identity test log listing the accounts checked and the result for each.
Replace the Mixpanel SDK with PostHog
Change the client and server instrumentation to the PostHog SDK, keeping the event names and properties from the mapping file. Run the old and new SDKs side by side in a staging environment first, then in production behind a flag if your release process supports it. Check that feature flags, consent handling and any identify calls behave as before. The output is a release note confirming that all tracked surfaces send events to PostHog and that the Mixpanel calls have been removed.
Validate reports and cohorts side by side
Build the priority dashboards, funnels and cohorts in PostHog and compare them with the Mixpanel versions over the same date ranges and timezone settings. Expect some differences because events are not deduplicated and the two tools count users differently, so record each variance and its cause. Sign-off comes when the agreed reports match within a tolerance the business owner accepted in writing. Only then should Mixpanel be turned down.
What buyers ask before choosing between Mixpanel and PostHog
What does a move from Mixpanel to PostHog cost in effort?
The effort is mostly people time: someone has to create the migration credentials, map event and property names, replace the Mixpanel SDK in the product, and verify that dashboards and cohorts still reconcile. The PostHog side of the historical import is documented as free of ingestion fees when events are sent with the historical_migration flag, but a paid product analytics plan is required to unlock the import features. Your costs therefore split into the PostHog plan you choose, the engineering and analytics hours on your side, and any partner fees if you buy implementation help. Ask any partner for a written scope that lists the event inventory, the SDK changes, the reconciliation steps and the cutover plan, because those items drive the hours.
How long does a full-history move take, and what drives the duration?
PostHog's managed migration imports historical events directly from Mixpanel through API credentials, and each direct import job covers at most one year of data. A full history therefore runs as a series of yearly jobs, so the number of years you keep and the volume of events in each year set the number of runs. Duration also depends on how many events you have, how clean your event and property names are, and how long it takes to check the results. Events are not deduplicated during import, so you should plan a step that removes or excludes overlapping runs before you compare counts. Confirm the current throughput and any rate limits with PostHog before you commit to a schedule.
Can we self-host PostHog without an implementation partner?
A small team can run the free Docker Compose hobby deployment, which PostHog installs with a deploy-hobby script under the MIT license. PostHog recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage for that deployment. The README says open-source deployments should scale to approximately 100k events per month, and recommends moving to PostHog Cloud above that. PostHog's self-host documentation also states that self-hosted deployments are officially unsupported and that PostHog does not offer customer support for product or infrastructure questions on self-hosted instances. Someone on your team therefore has to own upgrades, backups, monitoring and incident response, or you need an outside party for that work.
What does a PostHog license mean for premium features on a self-hosted instance?
PostHog's code is MIT licensed except for the ee directory, which is covered by a separate license. The README states that using premium features from the ee directory on a self-hosted instance requires a PostHog license. If you need fully free software, PostHog points you to the posthog-foss repository, which is purged of all proprietary code and features. Before you choose a path, list the features you need, such as SSO, audit logs, custom roles or project permissions, and check each one against the license file and the pricing page. The pricing page says SSO, audit logs, custom roles and project permissions are sold as platform packages, so ask PostHog to confirm the exact terms in writing.
What does the work need from our engineers and data owners?
Engineers must replace the Mixpanel SDK calls in your web and mobile code, keep event names and property names consistent, and make sure user identities carry across so that historical and new events join correctly. Data owners must confirm which events, properties and time ranges matter for their reports, cohorts and funnels, and they must agree on what counts as a match when the old and new numbers differ. Both groups should expect to review dashboard parity before cutover. Ask your team to inventory every tracked event now, because missing events are the most common source of surprises after a switch.
Which PostHog Cloud region should we choose for data residency?
PostHog's pricing page lists two Cloud hosting regions, US (Virginia) and EU (Frankfurt). Choose the region that matches your contractual and regulatory position, and confirm with your legal or privacy team how it fits your data transfer documentation. If your residency rules are stricter than a managed region can meet, self-hosting keeps the data in infrastructure you control, but it moves operational responsibility to your team. Confirm the region options and data processing terms with PostHog before you sign.
Does the migration remove old data from PostHog if we change our mind?
No. PostHog's migration documentation says there is no way to selectively delete event data once it has been imported. Treat each import as permanent for the events it includes, and test the import on a small date range or a non-production project before you run the full history. Keep the original Mixpanel data and your export files until your reconciliation is complete and your team has signed off on the results.
How DeployOpen helps evaluate, implement or migrate
DeployOpen is a Chainscore Labs company that 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 Mixpanel vs PostHog, that means turning the evaluation questions in this comparison into a written scope, a deployed and tested PostHog environment, and a handover your team can run.
How we scope
- Written scope agreed before work starts, covering which PostHog products and event volumes are in and out
- Review of your Mixpanel plan, retention needs, regional hosting requirements and data residency obligations
- Decision record on PostHog Cloud regions versus a self-hosted deployment, with the support and scale trade-offs stated
How we build
- Deployment of PostHog in your own infrastructure, sized against the hardware guidance in PostHog's self-host documentation
- Event mapping, identity handling and SDK replacement planned against your existing Mixpanel implementation
- Security testing of the deployed platform and its ingestion endpoints, with findings tracked to closure
How we hand over
- Runbooks covering installation, upgrades, backups, access controls and the migration steps that were run
- Documentation of licensing scope, including which features sit in the ee directory and whether a PostHog license is needed
- Handover sessions with your platform and analytics owners, with the written scope used as the acceptance reference
How we support
- Ongoing support, upgrades and continuous testing available as a retainer after handover
- Periodic review of event volume against the scale threshold PostHog publishes for open-source deployments
- Preparation of configuration, access and logging evidence for compliance assessments, with auditors issuing any formal opinion
