PostHog vs Mixpanel: Data Retention, Pricing, and SQL Access

The three things most comparisons miss

Most PostHog vs Mixpanel comparisons are feature matrices. They list session replay, A/B testing, and integrations side by side and call it done. That framing is fine for a five-minute skim, but it obscures the decisions that actually determine whether you will regret your choice in eighteen months.

In practice, the tool switching cost is dominated by three things: how much historical data you carry into a decision, how predictable your annual cost is, and whether your data team can interrogate raw events without building a separate pipeline. Everything else — the UI polish, the notification system, the Slack integration — is recoverable. These three are not.

This article goes deep on each one. It also covers the supporting differences (session replay depth, feature flags, deployment options) and lays out a genuine case for when Mixpanel is the right call. If you are already leaning toward migrating, the section on Mixpanel to PostHog migration covers the operational steps in detail.

What each platform is actually trying to do

Understanding the product philosophy helps predict how each platform will behave as your needs evolve.

PostHog: the product OS

PostHog launched as an open-source Mixpanel alternative in 2020 and has since expanded to include session replay, feature flags, A/B testing, surveys, and an internal data warehouse — all in a single platform. The driving thesis is that product teams should not need to stitch together five tools to answer a single question. The architecture is built on ClickHouse, which is what makes HogQL and the 7-year retention practical at the storage costs they charge.

PostHog is self-hostable. You can run the entire stack on your own infrastructure if data residency is a requirement. The open-source edition is actively maintained and the codebase is public on GitHub.

Mixpanel: behavioral analytics, refined

Mixpanel has been a product analytics category leader since 2009. Its core competency is making behavioral analytics — funnels, retention curves, user flows — accessible to product managers who do not write SQL. The UI is genuinely polished. Mixpanel has invested heavily in making complex queries expressible through a point-and-click interface.

It is cloud-only. There is no self-hosting option, and the underlying data store is not directly queryable. Mixpanel added session replay in 2024, but the feature set is narrower than PostHog's, and it is positioned as a UX observation tool rather than a technical debugging surface.

Differentiator 1: Data retention

This is the one most teams discover too late. You implement the tool, build dashboards, run the company off it for two years — and then discover that the cohort analysis you want to run requires data that was quietly deleted.

PostHog: up to 7 years

PostHog's paid cloud and self-hosted plans retain event data for up to 7 years. The free tier retains 1 year. The architectural reason this is feasible is ClickHouse's columnar storage model, which compresses event data aggressively. PostHog moves older, less frequently queried data to cold object storage (S3-compatible) while keeping recent data in hot ClickHouse storage. You can still query cold data via HogQL — it just takes longer to execute because the data has to be retrieved from object storage before ClickHouse can process it.

For most teams, this cold/hot distinction is invisible in day-to-day work. Dashboards querying the last 90 days run quickly. A query against 5-year-old event data takes longer — but it runs, and it returns the actual raw events. You are not working from an aggregate that was computed at ingestion time.

Mixpanel: 2 years default, enterprise custom

Mixpanel's default data retention is 2 years for most paid plans. This is an improvement over their earlier 12-month default, which some older comparison articles still cite. Custom retention periods are negotiable on enterprise agreements, but this is not a self-serve option — it requires a conversation with sales and typically appears in multi-year contracts.

The gap is most visible for three types of work:

• Multi-year cohort analysis. If you want to compare how your 2022 signup cohort behaved in year one versus how your 2024 cohort behaved in year one, you need three years of data. With Mixpanel's default 2-year window, that analysis disappears as events age out.
• Regulatory compliance. HIPAA, SOC 2 Type II, and some financial regulations have data retention requirements that exceed 2 years. If your product sits in a regulated category, Mixpanel's default window may put you in a position where you need a separate archival solution anyway — which negates part of the convenience argument for a managed SaaS.
• Post-schema migration context. Teams that migrate from a legacy event taxonomy to a new one often want to backfill context by querying old events to understand what behaviors preceded the schema change. A 2-year window limits how far back that context goes.

What this means for your data strategy

If you are on Mixpanel today and want to preserve data longer than 2 years, the typical workaround is to export to a data warehouse via Mixpanel's Data Pipelines feature and archive events there. This works, but it adds cost (the warehouse, the pipelines add-on) and complexity (schema maintenance across two systems). It also means the historical data lives in your warehouse rather than in Mixpanel's UI — so your PMs cannot browse it without a SQL query.

PostHog's model eliminates that split. Old data stays queryable in the same interface as recent data. For teams running a lean analytics stack where engineering capacity is scarce, that consolidation has real value.

Differentiator 2: Pricing transparency

Both platforms are usage-based. Both have public pricing pages. The difference is in what the headline numbers actually include — and what they do not.

PostHog: what you see is what you pay

PostHog's pricing is genuinely self-serve transparent. The pricing page shows a calculator: enter your monthly event volume, and the page returns your estimated bill. The step-down pricing structure means each event beyond the free tier costs progressively less as volume increases.

Critically, PostHog includes session replay, feature flags, A/B testing, surveys, and the data warehouse in the same usage-based billing model. You are not upsold on separate line items to access core functionality. Group Analytics — the feature that tracks companies and accounts rather than individual users, which is fundamental for B2B SaaS — is included without a separate fee.

For engineering-led teams who self-host, the software cost goes to zero. Infrastructure and maintenance cost replaces it, but for companies with existing DevOps capacity, self-hosting PostHog on cloud VMs is often substantially cheaper than the managed cloud plan at high event volumes.

Mixpanel: visible pricing, hidden total cost

Mixpanel's Growth tier pricing is publicly listed. The per-event rate is higher than PostHog's equivalent tier, but more importantly, several features that are table stakes for B2B product analytics are sold as add-ons or locked behind enterprise plans:

• Group Analytics. Tracking at the company level — essential for B2B SaaS where the buying unit is an organization, not an individual user — is an add-on on the Growth tier. The cost is non-trivial and is often a surprise to teams who assumed it was included.
• Data Pipelines. This is the feature that enables exporting Mixpanel data to an external data warehouse for SQL access. It is a separate product with separate pricing. If your data team needs to run SQL on your product data — and most data teams do — you will pay for this on top of your core analytics subscription.
• Advanced governance. Role-based access control beyond basic admin/viewer, data classification features, and compliance tooling sit on higher tiers or enterprise-only plans.

A note on total cost of ownership at scale

At low event volumes — under 5 million events per month — the cost difference between PostHog and Mixpanel is relatively small and probably not the deciding factor. At 50 million or 100 million events per month, the gap widens. If you are also paying for Group Analytics, Data Pipelines, and an external warehouse on Mixpanel, the total cost of ownership can be substantially higher than PostHog's equivalent cloud plan, before even accounting for PostHog's self-hosting option.

The right comparison is not headline-tier-vs-headline-tier. It is all-in cost for the feature set you actually need. Build your Mixpanel cost estimate by listing every feature your data team relies on and checking which plan tier or add-on activates each one.

Differentiator 3: SQL access

This one matters more than it sounds in early product conversations, and less than it sounds to engineering teams who have not yet felt the friction of a managed analytics tool.

The core question is: when your data team needs to ask a question the UI cannot answer, what happens next?

PostHog HogQL: SQL inside the product

HogQL is PostHog's SQL dialect, built directly on ClickHouse. It is available inside the PostHog interface without any additional setup or cost. You access it via the SQL Insights view or the built-in query editor. You can write JOIN queries across PostHog's internal tables — events, persons, sessions, groups — and save the results as dashboard insights.

Some examples of what this unlocks:

• Joining event data against person properties to compute cohort-level metrics that the standard funnel UI cannot express
• Writing custom activation metrics that combine multiple event conditions in a single query rather than stacking multiple Insight filters
• Debugging data quality issues by querying raw event payloads, including the properties your SDK sends, to confirm instrumentation is correct
• Defining SQL Expressions as derived properties that persist across the platform — so a computed metric built in HogQL becomes queryable in funnels, retention charts, and session replay filters

This query runs directly in PostHog's UI. No export, no warehouse, no ETL. For a data analyst who is used to writing SQL, having this available inside the same interface where the PM is reviewing funnels removes a significant friction point.

The limitation is honest: HogQL requires SQL proficiency. If your analytics consumers are PMs who do not write SQL, the PostHog UI handles most standard analyses — funnels, retention, cohorts, trends — without touching HogQL at all. But the SQL access is there when you need it, and it does not cost extra.

Mixpanel: the SQL workaround

Mixpanel does not expose a native SQL editor. Its underlying database is not directly queryable. The path to SQL access involves two steps that add cost and complexity:

First, you need Mixpanel's Data Pipelines feature, which exports event data to an external data warehouse — Snowflake, BigQuery, or Redshift. This is a paid add-on. The export is not real-time; depending on your plan and configuration, there is typically a delay of several hours between an event occurring and it appearing in your warehouse.

Second, you need to manage the warehouse itself — schema maintenance, compute costs, access controls, and the query tooling that sits on top (dbt, Metabase, Looker, or direct SQL clients). For teams that already have a mature data stack, this may be a natural fit. For teams that do not, it is substantial additional infrastructure to stand up before you can run your first custom SQL query against your product data.

Mixpanel does offer JQL (JavaScript Query Language) as a way to perform more advanced queries within the platform. JQL is more flexible than the standard UI but is not SQL — it requires JavaScript and has a steeper learning curve than either the Mixpanel UI or HogQL. It is not commonly used outside of advanced technical users.

What this means for data team workflows

The SQL question maps directly to a team maturity question. An early-stage company with one data analyst and a shared product/data role will find PostHog's SQL access a meaningful accelerator. A mid-market company with a dedicated data platform team, an existing Snowflake contract, and a Looker deployment may already have the infrastructure to absorb Mixpanel's export model — the additional cost of Data Pipelines is real but not structurally prohibitive.

The risk to watch is the latency gap. When you are debugging a funnel drop or investigating an anomaly in activation data, working from a warehouse export that is 6–12 hours stale creates friction. HogQL queries run against live data. If fast iteration cycles matter to your team, this gap compounds over time.

For teams building a data-driven product analytics practice, the ability to close the loop between a question and a SQL answer inside one tool — without a context switch to Snowflake — meaningfully changes the velocity of analysis.

Other differences worth knowing

The three differentiators above drive most platform decisions. These secondary differences are worth understanding but are unlikely to be the deciding factor on their own.

Session replay depth

Both platforms include session replay. PostHog's implementation is more technically detailed — replays include console logs, network requests, and performance metrics alongside the visual recording. This makes it genuinely useful for debugging rendering issues, slow load times, and JavaScript errors in addition to user experience observation.

Mixpanel's session replay is focused on the UX side. It shows what users did but not why the page behaved as it did. For a PM analyzing a funnel step where users are dropping off, Mixpanel's replay is adequate. For an engineer investigating why a modal is not closing, PostHog's console log capture is essential.

Feature flags and A/B testing

PostHog includes feature flags and A/B testing as part of its standard platform. The flag evaluation is done client-side or server-side via SDK, and the results feed back into PostHog's analytics automatically — so you can build a funnel that segments users by flag variant without any additional instrumentation. The PostHog A/B experiment setup is straightforward if you are already using the PostHog SDK.

Mixpanel's experiment tooling is available on higher-tier plans and is less tightly integrated with the analytics layer. Teams using Mixpanel for analytics and LaunchDarkly or Statsig for flags are a common pattern — the integration works, but it requires an additional SDK and the variant data has to be sent to Mixpanel as a property on events, which adds instrumentation overhead.

Deployment and data sovereignty

PostHog's self-hosting option is meaningful for companies in regulated industries or those with data residency requirements. You can run PostHog on your own infrastructure in any cloud region, and your event data never leaves your environment. This is the practical path for HIPAA-compliant product analytics without relying on a Business Associate Agreement with a third-party vendor.

Mixpanel is cloud-only. Data residency is handled via region selection (US or EU), but the data still sits on Mixpanel's infrastructure. For most B2B SaaS companies this is fine. For healthcare, fintech, and government-adjacent products, the self-hosting option PostHog provides changes the compliance conversation substantially.

UI and ease of use

Mixpanel's UI is genuinely better for non-technical users. The funnel builder, retention analysis, and user flow charts are polished and require no instruction to use for someone with product analytics literacy. A new PM can spin up a meaningful funnel analysis within an hour of getting access.

PostHog's UI has improved significantly since the early open-source releases, but it is designed for a more technical audience. The concepts are exposed in a way that gives analysts more control — at the cost of requiring slightly more familiarity with how the underlying data model works. If your primary analytics consumer is a PM who does not write SQL and values self-service speed, this difference is real.

When Mixpanel is the right choice

This article is not making a universal argument for PostHog. There are genuine situations where Mixpanel is the better fit, and understating that would make this comparison less useful.

PM-led organizations without in-house data analysts

If your analytics consumers are product managers who need to answer questions quickly using a polished UI, and you do not have a data analyst to write HogQL queries or manage a ClickHouse schema, Mixpanel's self-service model will serve you better day-to-day. PostHog's power is most accessible to people who are comfortable with SQL and data modeling concepts. Mixpanel abstracts more of that complexity.

Teams with existing Mixpanel expertise

Event taxonomy decisions accumulate over years. A team that has spent three years carefully building a Mixpanel event schema, training PMs on how to use it, and integrating it with downstream tools has embedded knowledge that has real economic value. Migrating to PostHog means a period of parallel-run cost, retraining, and disruption to existing dashboards. If Mixpanel's retention and SQL limitations are not causing active pain, the switching cost is a genuine argument to stay.

Simpler setup for non-engineering-led teams

Mixpanel's SDKs are simpler to instrument for straightforward use cases. PostHog is also straightforward to set up, but the full value of the platform — HogQL, the data warehouse, the session replay console logs — requires more engineering involvement to unlock. If your team is lean and engineering capacity is the binding constraint, Mixpanel may get you to working dashboards faster.

When 2 years of retention is sufficient

For early-stage companies that have not yet accumulated 2 years of meaningful data, Mixpanel's retention window is not a practical constraint. If you are pre-product-market-fit and optimizing for speed of insight over long-term historical depth, this difference does not matter today — though it may in 24 months.

Migrating from Mixpanel to PostHog

If you are evaluating this comparison because you are actively considering a migration, here is the practical overview. For full operational detail, the Mixpanel to PostHog migration guide covers the step-by-step process including SDK conversion and HIPAA considerations.

What transfers and what does not

Your event taxonomy transfers — the names and structures of your events are determined by your instrumentation, not by Mixpanel, so you can replicate them in PostHog's SDK. User properties and group properties carry over in the same way.

What does not transfer: historical event data. PostHog does not have a Mixpanel data importer. Your historical events stay in Mixpanel's system. If you need to retain query access to old data, you have two options: keep your Mixpanel account active (on a reduced plan if possible) during the transition period, or export your Mixpanel data to a data warehouse before canceling. Given that PostHog's 7-year retention is one of the reasons to migrate, it is worth setting a clean start date in PostHog and letting the new history accumulate there.

The parallel-run period

The standard approach is to run PostHog alongside Mixpanel for 30–90 days. Fire events to both platforms simultaneously. This gives you a PostHog baseline to validate against your existing Mixpanel dashboards before you cut over. It also gives your team time to rebuild the dashboards and analyses they rely on daily before losing access to the Mixpanel versions.

The parallel-run costs money — you are paying for two platforms. But the cost of a bad cutover (discovering after the fact that a critical metric is not instrumented correctly in PostHog) is higher.

SDK migration

If you are using Mixpanel's JavaScript SDK, the PostHog equivalent is a drop-in replacement for most standard event tracking calls. The property naming conventions differ slightly — PostHog uses snake_case by default — but the call structure is the same. Where Mixpanel uses mixpanel.track(), PostHog uses posthog.capture(). For mobile SDKs (iOS, Android) and server-side integrations, the PostHog documentation covers the equivalent calls for each platform.

How to make the decision

Here is a practical framework for working through the choice.

Choose PostHog if

• Your team includes engineers or data analysts who will write SQL queries against product data
• You are in a regulated industry (healthcare, fintech, government) and data sovereignty or long retention is a requirement
• You want to consolidate feature flags, A/B testing, and session replay into one platform
• You are at a volume where Mixpanel's add-on costs (Group Analytics, Data Pipelines) materially increase your total bill
• You have more than 2 years of meaningful event history and intend to run multi-year cohort analyses
• You are starting fresh and do not have legacy Mixpanel expertise to preserve

Choose Mixpanel if

• Your analytics consumers are primarily PMs who need polished self-service funnels without SQL proficiency
• Your team has deep Mixpanel expertise and a well-structured event schema that would take 6+ months to rebuild
• You are pre-PMF and speed to working dashboards is the binding constraint
• Your data team already manages a mature warehouse and absorbing Data Pipelines cost is not a concern
• You value Mixpanel's UI for non-technical stakeholders who pull their own reports

FAQ

How long does PostHog retain data compared to Mixpanel?

PostHog retains data for up to 7 years on paid cloud and self-hosted plans (1 year on the free tier). Mixpanel's default retention is 2 years for most paid plans, with custom longer periods available on negotiated enterprise agreements. For long-term trend analysis or compliance use cases, PostHog's retention window is substantially larger.

Does PostHog have SQL access?

Yes. PostHog includes HogQL — a native SQL dialect built on its ClickHouse backend. You can run ad-hoc queries, define SQL Expressions as derived properties, and build custom insights directly inside the platform without exporting data. Mixpanel does not offer a native SQL editor; SQL queries require exporting data to an external warehouse via the Data Pipelines add-on.

Is PostHog cheaper than Mixpanel?

PostHog's per-event pricing is generally lower than Mixpanel's Growth tier, and most core features (session replay, feature flags, A/B testing) are included without add-ons. Mixpanel's total cost of ownership tends to increase materially once Group Analytics (essential for B2B) and Data Pipelines are added. The cost gap widens with scale.

When should I choose Mixpanel over PostHog?

Mixpanel wins when your team is PM-led rather than engineering-led, when you need a polished UI for non-technical users to self-serve funnel analysis, or when your team already has deep Mixpanel expertise and a working event schema. Retraining a mature Mixpanel team has real costs that a pricing comparison alone does not capture.

Can I migrate from Mixpanel to PostHog without losing historical data?

You can migrate event schemas and ongoing instrumentation relatively cleanly, but historical Mixpanel data does not import directly into PostHog's analytics. The practical approach is to run both in parallel for 30–90 days to build a comparable baseline in PostHog before decommissioning Mixpanel. The migration guide covers the step-by-step process.

Sources

• PostHog Pricing — Self-serve calculator, plan details, and feature inclusion matrix
• PostHog HogQL Documentation — Query language reference, supported functions, and SQL Insights guide
• PostHog Data Retention Documentation — Retention policy by plan tier, hot vs cold storage behavior
• Mixpanel Pricing — Growth and Enterprise plan features and pricing
• Mixpanel Data Retention Documentation — Default retention policy and enterprise options
• Mixpanel Data Pipelines — Export capabilities, supported destinations, pricing model

Migrate to PostHog

We manage the event taxonomy rebuild and data migration. Zero downtime.