Mixpanel cost vs self-hosted PostHog: where the total really lands
The answer depends on event volume, in-house skills and how much support you need, not on license fees alone. PostHog's core is MIT licensed, so the software itself costs nothing to run, but the server, storage, engineering time and any outside help are real line items. A buyer weighing a Mixpanel renewal or pricing change should model those costs against their own event counts before comparing totals.
Self-hosting tends to cost less at low to moderate volume when the team already runs Docker and Linux servers. PostHog's self-host documentation describes a free Docker Compose hobby deployment 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 PostHog README says open-source deployments should scale to approximately 100k events per month and recommends moving to PostHog Cloud above that, while PostHog Cloud includes the first 1 million analytics events free each month.
Self-hosting tends to cost more as volume grows and when uptime becomes a duty. Above the roughly 100k events per month guidance, the hardware, database tuning, upgrades, backups and on-call work all scale with your traffic, and PostHog states that self-hosted deployments are officially unsupported and that it offers no customer support for infrastructure questions. New Kubernetes deployments of its paid self-hosted product are no longer supported, so confirm the deployment method you plan to run before you size anything. Ask a potential implementation partner for a written scope covering sizing, monitoring, backups and upgrades, and compare that quote with Mixpanel's own renewal terms and your internal staffing cost.
Which cost components apply on each side
This table sets Mixpanel's subscription and data terms against PostHog Cloud usage fees and a self-hosted PostHog deployment, row by row. Read each row for who is paid, whether the cost is one-time or recurring, and what changes it. The main takeaway is that the self-hosted option removes the subscription line but adds infrastructure, migration and staff time that you must price yourself.
| Cost component | Mixpanel (commercial side) | PostHog (self-hosted or Cloud side) | One-time or recurring |
|---|---|---|---|
| Subscription or license | Recurring plan fees tied to event volume and features, set by Mixpanel's pricing page at the time you buy. Confirm the current tier and event limits in writing. | PostHog Cloud bills usage after the first 1 million analytics events each month (per PostHog's pricing page). Self-hosted MIT core has no license fee, but premium features in the ee directory need a PostHog license. | Recurring |
| Data export and retention effects | Retention is set by plan. Exporting full history through the Raw Event Export API costs staff time and may need a longer extraction window. | Plan-based retention on Cloud (1-year on Free, 7-year on Pay-as-you-go, per PostHog's pricing page). Self-hosted retention is set by your own storage policy. | Recurring |
| Hosting and infrastructure | None. Mixpanel hosts the platform, with regional endpoints for EU and India residency. | Self-hosted cost covers servers, storage, backups and networking. PostHog's self-host docs recommend a server equivalent to 4 vCPU, 16 GB RAM and more than 30 GB of storage for the hobby deployment. | Recurring |
| Implementation and data migration | Limited to SDK and tracking plan work already done for Mixpanel. Direct import is not covered by the subscription alone. | Managed migration imports from Mixpanel with API credentials, in jobs of at most one year each. Historical imports need a paid product analytics plan to unlock import features, and imported events are not deduplicated. | One-time |
| Ongoing operations and upgrades | Handled by Mixpanel. Your team only manages SDK versions and tracking changes. | Your team runs patching, upgrades and database maintenance. PostHog no longer supports new Kubernetes deployments of its paid self-hosted product, so plan the deployment method first. | Recurring |
| Support | Included in the Mixpanel contract, with support tiers set by plan. | Self-hosted instances are officially unsupported, and PostHog does not offer customer support for product or infrastructure questions. Budget for an implementation partner or internal expertise. | Recurring |
| Internal skills and staff time | Limited to analysts and product owners using reports, cohorts and funnels. | Requires DevOps, database and security staff for hosting, scaling and incident response, in addition to analysts. Confirm this headcount against your own environment. | Recurring |
| Enterprise features | SSO, audit logs and advanced access controls are part of the commercial offer, as set by your plan. | PostHog Cloud sells SSO, audit logs, custom roles and project permissions as platform packages. Self-hosted premium features require a PostHog license for the ee directory, so ask for a quote covering both. | Not applicable |
What moves the comparison as event volume grows
Mixpanel cost against self-hosted PostHog depends less on today's bill than on how four variables move over the next few years. Self-hosting costs stay fairly flat at small scale and rise with operations load, while PostHog Cloud usage fees rise with every event, so the two curves cross at a point that depends on your own volume and staffing.
Monthly event volume
PostHog Cloud includes the first 1 million analytics events each month free, which covers many small products entirely. Above that, Cloud charges by usage, so cost grows in a straight line with volume. The README says open-source deployments should scale to approximately 100k events per month and recommends PostHog Cloud above that. Measure your current monthly events by product and forecast growth before comparing totals.
Projects and retention needs
The Free plan includes 1 project and 1-year data retention, while Pay-as-you-go raises this to 6 projects and 7-year retention. Mixpanel's default retention is 2 years, so teams with longer analysis windows may need a paid Cloud plan or a self-hosted instance where they set retention themselves. Count the projects you need and the history your analysts actually query.
Enterprise features under the ee license
Premium features in the ee directory, such as SSO, audit logs, custom roles and project permissions, require a PostHog license on self-hosted instances. On Cloud, PostHog sells these as platform packages. Confirm which controls your security and compliance reviews require, then price them as a separate line item, since the posthog-foss repository omits them entirely.
Availability and on-call expectations
PostHog states that self-hosted deployments are officially unsupported and that it offers no customer support for product or infrastructure questions on self-hosted instances. Your team owns uptime, upgrades, backups and incident response. As volume grows, the staff hours for these tasks become the largest variable cost, so ask who covers nights and weekends before you commit.
In-house platform skills
Self-hosting needs people who can run Docker Compose or Kubernetes, manage PostgreSQL and ClickHouse storage, and tune ingestion as traffic rises. PostHog's recommended starting server is 4 vCPU, 16 GB RAM and more than 30 GB of storage. Confirm whether your platform team already runs these components, or whether a fixed-scope implementation and retainer support would cover the gap.
How to build the comparison with your own numbers
This sequence turns the published Mixpanel and PostHog figures into a comparison built on your own event volumes, feature use, staffing and migration effort, so the cost curves reflect your organization rather than a generic estimate.
Export current Mixpanel event counts
A product analytics owner, with help from whoever administers the Mixpanel project, pulls monthly event counts for the last 12 months and records peak months, the number of distinct event names and the share of traffic from each product area. Your team must supply these figures from the Mixpanel project itself, since they are specific to your implementation. Record the retention window your teams actually query, not the one you have configured. The step is done when you have a single table of monthly events, event names and required lookback that another person on the team can reproduce from the same export.
Inventory the features your teams use
Product managers and analysts list the reports, cohorts, funnels, flags, experiments, surveys and session replay views they use each week, and mark each as core, occasional or unused. Your team must supply this list, because usage varies by organization. Compare the list with what PostHog's README groups as its product areas and note which features would stay on another tool. The output is a feature register that tells you which PostHog products you would actually enable, which affects whether you need a Cloud paid plan, platform packages or only the core analytics tier.
Price PostHog Cloud against your forecast
A finance or procurement lead applies the event forecast from step one to PostHog's pricing page, using the free monthly allowance and the plan limits it lists for projects and data retention. Your team must confirm current rates and any platform package charges directly on that page or in a written quote, because usage rates change. Model the cost at your current volume, at expected growth and at a peak month. The result is a per-month and per-year Cloud cost for each scenario, with the assumptions written beside it.
Size a self-hosted server against the baseline
An infrastructure engineer compares your forecast with the server baseline in PostHog's self-host documentation, which 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. Your team must confirm that baseline for your own event volume, because the README says open-source deployments should scale to approximately 100k events per month. Above that level, PostHog recommends Cloud, which means the self-hosted cost curve does not extend indefinitely. The output is a sizing note that states the instance type, storage growth, backup target and the volume at which you would stop self-hosting.
Estimate engineering hours for operations
The platform engineering lead estimates hours for installing the stack, applying upgrades, running backups, monitoring the instance and handling incidents, using your own staff rates and on-call model. PostHog states that self-hosted deployments are officially unsupported and that it does not provide customer support for product or infrastructure questions on them, so the hours belong to your team or to a partner you contract separately. Your team must supply the rates and the time estimate. Separate one-time setup from recurring operations, and note that new Kubernetes deployments of PostHog's paid self-hosted product are no longer supported. The output is a staffing table with setup hours and monthly operating hours.
Add migration effort and mapping work
A data engineer estimates the migration work from Mixpanel, which includes running PostHog's managed migration. Direct imports cover at most one year of data per job, so multi-year history needs several jobs, and events are not deduplicated. Unmapped or inconsistent event names will need a mapping table, and there is no way to selectively delete imported event data. Your team must supply the number of years of history, the count of event and property names and the people who will approve the mapping. Note that a paid product analytics plan is required to unlock the import features, so add that cost to the migration line. The output is a one-time migration cost with its assumptions listed.
Run three volume scenarios
The finance lead and platform engineer combine the earlier outputs into three scenarios, labeled low, expected and high, and compare the Mixpanel Growth tier cost, PostHog Cloud cost and self-hosted cost for each over the same period. Illustrative example only: if expected monthly volume sits well above the self-hosting threshold, the self-hosted line will show the operations cost rising quickly while the Cloud line scales with usage. Your team must choose the scenario values. The check is that each scenario states its volume, retention, enabled features and staffing assumption, so the result can be reviewed and rerun when volume changes.
What migration adds to the one-time cost
The one-time cost of moving from Mixpanel to PostHog is driven mostly by history import, not by software. PostHog's managed migration pulls historical events directly from Mixpanel using API credentials, or reads JSONL files staged in an S3 bucket. Each direct import job covers at most one year of data, so a multi-year history needs several jobs, each run and checked in turn. Events are not deduplicated, so re-running an overlapping date range can create duplicate events. Confirm with your Mixpanel administrator which service account or project secret will be used, who holds it, and when it is revoked after the import.
Imports sent with the historical_migration flag avoid ingestion fees, but PostHog's migration documentation says a paid product analytics plan is required to unlock the import features. Budget for that plan for the duration of the migration, and ask PostHog to confirm in writing which plan and event volumes the import jobs count against. Also plan for irreversibility: there is no way to selectively delete event data once it is imported, so a bad mapping or a wrong date range stays in the project. Test the first job against a non-production project and review the results before importing the full history.
The larger effort drivers are the SDK replacement and the period of dual running. Every Mixpanel SDK call in web, mobile and server code must be mapped to PostHog equivalents, and event and property names must be mapped so that historical and new data can be compared in the same reports. Dual running, where both tools receive events while teams validate dashboards, multiplies collection work and vendor spend for as long as it lasts. For the export side and the step-by-step import, see the sibling pages on exporting your data from Mixpanel and migrating from Mixpanel to PostHog, which cover the details this section does not.
Questions buyers ask before comparing cost
Is self-hosting PostHog free?
The core is free, but the total cost is not zero. PostHog's repository is under the MIT Expat license except for the ee/ directory, which carries a separate license. The PostHog README states that premium features from ee on a self-hosted instance require a PostHog license. If you need fully free software, the posthog-foss repository is purged of all proprietary code and features, so you give up those features. Even with no license fee, you pay for the server, storage, backups, and the engineers who install, patch and monitor the system. Those staff costs are real and recur every month, so compare them with Mixpanel's subscription, not with zero.
How much effort does self-hosting PostHog take?
The effort depends on the deployment path and on your event volume. PostHog offers a 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. Effort rises with volume, retention, high availability, upgrades and backups. The drivers to scope are how many events you ingest, how long you keep data, how many people run the system, and whether you need premium features that require a license. Ask any provider, including an outside partner, to estimate effort from those drivers in writing rather than from a generic number.
Can a small team run self-hosted PostHog alone?
A small team can run it, but only if it has people who can operate a multi-service analytics stack without vendor help. PostHog's self-host documentation states that self-hosted deployments are officially unsupported and that PostHog does not provide customer support for product, infrastructure or other questions on self-hosted instances. That means your team owns container orchestration, databases, ingestion capacity, upgrades, backups and incident response. Before committing, confirm that you have Linux, container, database and networking skills on call, a documented upgrade and rollback procedure, and a restore test for backups. If those skills are thin, a fixed-scope outside partner can cover parts of this work in writing.
When should a team move from self-hosted PostHog to PostHog Cloud?
PostHog's README says open-source deployments should scale to approximately 100k events per month and recommends migrating to PostHog Cloud above that level. Treat this as vendor guidance, not a hard limit, and measure your own ingestion before deciding. Above that volume, staff time spent on capacity and tuning tends to grow faster than the cost of a hosted plan. PostHog's pricing page states that the first 1 million analytics events are free every month, so Cloud can cost little at low volume, but you should check current rates on that page for your volume. Also note that PostHog's self-host docs say new Kubernetes deployments of its paid self-hosted product are no longer supported.
Can I trim historical events from PostHog after a migration?
No, not selectively. PostHog's migration documentation states that there is no way to selectively delete event data once it has been imported. Each direct import from Mixpanel or Amplitude covers at most one year of data, and events are not deduplicated, so a repeated or overlapping job can duplicate records. Before importing, decide which date ranges, event names and properties you need, and export or filter the data first. Test the import on a small window in a non-production project. Keep in mind that the historical_migration flag makes imports free of ingestion fees, but a paid product analytics plan is required to unlock the import features.
Does a fixed-scope outside partner change the cost math?
It can, because it turns some unpredictable internal effort into a scoped cost you agree in advance. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and testing are available as retainers. DeployOpen does not publish a price list, so ask for a quote built from your written scope. A partner does not remove the recurring infrastructure cost or the license terms for premium features, and it does not replace your own ownership of the data.
Where each option's cost curve bends
Mixpanel's cost moves in steps. It follows the plan tier you are on and the event allowance that tier includes, so the bill stays flat until volume or feature needs push you into a higher tier. Before you model that curve, pull the current tier names, event limits and add-on terms from Mixpanel's pricing page and a written quote, because those are the figures that set your first step. PostHog Cloud behaves differently. Its usage pricing starts after the first 1 million analytics events each month, which are free, so cost rises roughly with event volume beyond that threshold. Check the per-event rates and any product-specific meters for the features you use, since session replay, feature flags and surveys may be billed separately from product analytics.
Self-hosted PostHog has a different shape. It has no per-event fee, but it carries a fixed floor: the server, storage, backups, monitoring and the engineering time to run them. The PostHog README says open-source deployments should scale to approximately 100k events per month and recommends moving to PostHog Cloud above that, so treat that figure as the point where self-hosting usually stops being the cheaper path for analytics alone. Costs then rise in steps when you need higher availability, larger ClickHouse capacity, retention beyond what you can store cheaply, or compliance evidence. PostHog's self-host documentation also states that self-hosted deployments are officially unsupported, so any support you need comes from your own staff or a partner.
The crossover point depends on your own numbers, so build it in a model with three inputs: your monthly event count and its growth, the tier and per-event rates in each quote, and the fully loaded cost of the infrastructure and staff time you would commit to self-hosting. Add a fourth input for the one-time migration work, including the managed import from Mixpanel, which PostHog documents as one-year jobs, and the SDK replacement. Ask Mixpanel and PostHog for quotes against the same event forecast, and ask DeployOpen for a written scope if you want the self-hosting side priced from your environment. Then run the model at your current volume, at double it and at the volume where you expect a compliance requirement to add cost, because the crossover often moves more than the unit price does.
How residency requirements change the cost picture
Residency requirements can change the cost comparison more than list prices do, because they decide which deployment options are even allowed. PostHog Cloud offers two hosting regions, US (Virginia) and EU (Frankfurt), so an EU residency requirement may be met on Cloud without operating anything yourself. Confirm with PostHog which region your project is created in, whether any processing or support access leaves that region, and whether the Cloud plan you need includes the controls your auditors will ask about, since SSO, audit logs, custom roles and project permissions are sold as platform packages.
Self-hosting keeps event data inside your own infrastructure, whether that is a cloud account you control, a data center or an isolated network. That removes the question of where the vendor stores data, but it moves the full cost of operating the platform onto your team: servers, storage, backups, upgrades, security patching, and the on-call time to run them. PostHog's self-host documentation states that self-hosted deployments are officially unsupported and that PostHog does not offer customer support for product or infrastructure questions on them, so any support you need comes from your own staff or a partner you contract separately. Ask for the cost of that support in writing, not as an assumption.
For transfers, the European Commission's adequacy decision of July 10, 2023 (decision 2023/1795) allows personal data to flow from the EU to US companies that participate in the EU-US Data Privacy Framework. Whether a given vendor and its sub-processors participate is something you verify, not assume, and whether that decision covers your processing is a legal question. Confirm your own transfer position, including the transfer mechanism, sub-processor list and data processing terms, with your counsel before you compare a Cloud region choice against the cost of self-hosting.
How DeployOpen scopes a fixed-price PostHog implementation
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Mixpanel cost vs self-hosted PostHog decision, we start with a written scope that compares your actual event volume, retention needs and support model before any build work begins.
How we scope
- Inventory the Mixpanel events, properties, funnels, cohorts and dashboards your teams depend on today.
- Agree in writing which PostHog products, retention settings and hosting model are in and out of scope.
- Size the self-hosted infrastructure against your projected monthly event volume and recovery expectations.
- Confirm with PostHog which features in the ee directory your scope needs, since they require a license.
How we build
- Deploy PostHog in your own environment, using the hosting approach and infrastructure agreed in scope.
- Configure SDK instrumentation, identity handling and event naming to match your existing Mixpanel data model.
- Test ingestion volumes, dashboard accuracy and access controls before any production traffic is switched over.
- Plan the historical import in one-year jobs and document how duplicate events will be handled.
How we hand over
- Deliver architecture, configuration and runbook documentation covering the full self-hosted PostHog stack.
- Document the cost components you own, including infrastructure, storage, backups and upgrade effort.
- Provide a cost model that shows which items are one-time and which recur as event volume grows.
- Walk your platform and analytics teams through operations, upgrades and the Mixpanel decommissioning steps.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Keep backups, restore tests and version upgrades on a documented schedule agreed in the retainer scope.
- Note that PostHog does not provide customer support for self-hosted instances, so support terms must be planned.
- Request a quote based on the written scope, since DeployOpen does not publish a price list.
