Amplitude vs PostHog: which fits your product analytics?
The decision usually starts with a renewal, an event-based price increase, or a residency requirement that makes you ask where product events are stored. Amplitude fits teams that want a mature, managed product analytics service with funnels, retention and cohorts, and no operating burden on their own engineers. You pay for the platform and the vendor runs it. PostHog fits teams that want product analytics bundled with session replay, feature flags and experiments in one product, and that want control over where the data is hosted. Its code is MIT licensed apart from the ee directory, and it offers PostHog Cloud in a US (Virginia) region and an EU (Frankfurt) region, as listed on the PostHog pricing page.
The two paths differ in what you operate. PostHog Cloud is the managed option for teams that want PostHog's bundle without running servers, and it has a free monthly allowance of 1 million analytics events. Self-hosting is a different job. PostHog's self-host documentation describes the free Docker Compose hobby deployment as officially unsupported, with no customer support for product or infrastructure questions, and it recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage. Confirm with PostHog which deployment type fits your volume and whether SSO, audit logs and custom roles, which are sold as platform packages, are needed for your access model.
Four factors decide it: expected event volume, data residency obligations, in-house operating capacity, and how much of the bundle you will actually use. If you only need product funnels and retention, a managed Amplitude plan may cost less to run than a self-hosted PostHog you must staff. If you plan to use replay, flags and experiments together and must keep data in a specific region, PostHog Cloud EU or a self-hosted instance deserves a closer look. Before you decide, pull your last twelve months of event counts, list the data regions your legal team will accept, and name the engineer who will own upgrades and backups.
Which option fits which scenario
This table matches common team situations to the option that usually fits better and the condition that drives the choice. Read each row against your own event volume, hosting rules and existing tooling, then confirm the details with PostHog and your own environment before committing.
| Scenario | Better fit | Condition that drives it |
|---|---|---|
| Small team with modest event volume | PostHog Cloud | PostHog's pricing page says the first 1 million analytics events are free every month, so a team below that volume can start without an ingestion bill. Confirm how Amplitude's current plan limits compare for your volume. |
| Team that needs EU hosting | PostHog Cloud EU (Frankfurt) | PostHog lists an EU (Frankfurt) region alongside US (Virginia). Confirm where each event is stored and processed, and whether your data processing terms cover it. |
| Team with strict self-hosting rules | Self-hosted PostHog, with a supported deployment plan | The free hobby deployment is officially unsupported, and PostHog does not offer customer support for self-hosted instances. Teams with strict rules should ask for a supported path and written scope before choosing this route. |
| Team that wants a free-software-only deployment | Self-hosted posthog-foss | The posthog-foss repository is purged of all proprietary code and features, while premium features in the ee directory need a PostHog license. Confirm which features your team needs before relying on it. |
| Team that already uses feature flags or experiments | PostHog, if analytics and flags should share one tool | PostHog bundles feature flags and experiments with product analytics and session replay. Teams already running a separate flag service should compare migration cost against the benefit of consolidation. |
| Team with an in-house platform group | Self-hosted PostHog, operated by the platform group | The README recommends migrating to PostHog Cloud above roughly 100k events per month for open-source deployments. Platform teams should size compute and storage against the documented server guidance and plan for upgrades and backups themselves. |
| Team with high event volume and an existing Amplitude history | PostHog Cloud, with a planned managed import | PostHog's managed migration imports historical events from Amplitude in jobs covering at most one year each, and events are not deduplicated. Plan job order and duplicate checks before importing. |
| Team that needs selective deletion of imported data | Confirm before choosing PostHog | PostHog's migration documentation states there is no way to selectively delete event data once imported. Confirm retention and deletion requirements with your privacy team first. |
Where your event data lives and who can access it
Event data for product analytics is often personal data, so where it is stored and who can administer it matters as much as the features. PostHog offers two Cloud regions, a self-hosted option in your own infrastructure and a free hobby deployment that carries no vendor support, and these choices change your compliance position.
PostHog Cloud regions
PostHog Cloud lists two hosting regions: US (Virginia) and EU (Frankfurt). Choose the region when the project is created, and record it in your data inventory and records of processing. Confirm with PostHog whether any event data, backups, support access or sub-processors sit outside the region you select, and get the answer in writing before you send production traffic.
Self-hosted PostHog in your infrastructure
Self-hosting keeps events, person profiles and replay data inside your own cloud account, data center or private network, so no third-party processor receives them. You take on operations: patching, backups, database and storage sizing, and access to the servers. Your own team or an implementation partner carries that responsibility, so define who holds it before you choose this route.
Hobby deployment and its support gap
The free Docker Compose hobby deployment is MIT licensed and suitable for evaluation, but PostHog states that self-hosted deployments are officially unsupported and that it does not provide customer support for infrastructure questions. If the data is regulated, a hobby install without a named owner for patching and recovery is a control gap, not a cost saving. Plan an operating model before going live.
EU-US Data Privacy Framework for US processing
If you use the US Cloud region, or any US-headquartered vendor processes personal data, the EU-US Data Privacy Framework can serve as the transfer basis. The European Commission adopted its adequacy decision on July 10, 2023 (decision 2023/1795). Confirm that the vendor participates in the framework and that its listing covers the data you send, and document the transfer in your assessment rather than assuming it.
Identity and audit controls
SSO, audit logs, custom roles and project permissions are sold as PostHog platform packages, not included in the free tiers. Map each control to your access policy: who may export events, change retention, or view replay recordings. Ask the vendor which controls the paid package includes, and whether a self-hosted deployment needs a license for them under the ee directory.
How event pricing changes the math at your volume
Amplitude bills against its own plan units, so the comparison starts with which unit your current contract meters, whether that is events or monthly tracked users. PostHog Cloud meters differently. The PostHog pricing page states that the first 1 million analytics events are free each month, that the Free plan includes 1 project and 1-year data retention, and that Pay-as-you-go raises this to 6 projects and 7-year retention. Session replay, feature flags and experiments carry their own free tiers, so each product you switch on adds its own line. On PostHog, cost therefore rises with event volume, how long history must stay queryable, the number of products in use, and platform features such as SSO, audit logs, custom roles and project permissions, which PostHog sells as platform packages.
Self-hosting moves cost from the vendor invoice to your own infrastructure and staff. PostHog's README says open-source deployments should scale to approximately 100k events per month and recommends moving to PostHog Cloud above that level. Its self-host documentation describes the hobby deployment as officially unsupported, with no vendor support for product or infrastructure questions, and recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage. Above roughly 100k events a month, the server bill, the monthly time spent on patching, backups and upgrades, and the lack of vendor support can outweigh the savings on the license line. Ask your platform team to estimate those recurring hours before comparing options.
Build the comparison from your own usage data and confirm it in writing. Export 12 months of event counts by month from Amplitude, along with monthly tracked users if your contract uses them, and list the products and seats your teams actually use. Then model three PostHog scenarios: Cloud within the free allowance, Cloud on Pay-as-you-go with your retention requirement, and self-hosted at your volume. Ask Amplitude for a quote against that same usage file, and confirm whether it covers the data region you need. If you plan to bring history across, include a paid product analytics plan in the Cloud scenario, because PostHog's migration documentation says that plan is required to unlock the import features.
Cost components on each side
Amplitude and PostHog both charge for usage, but the cost of running PostHog yourself is spread across servers, people and the support you buy or do without. Compare the components below on each side, and separate what you pay once from what recurs.
Amplitude subscription and usage fees
Amplitude bills on its own plan structure, so the recurring cost depends on the plan tier, the monthly tracked users or events you are billed for, and any add-on products you enable. Expect this line to grow with traffic and with the number of products you adopt. Ask the vendor to quote your current volume and the plan that matches your features, including experiments and session replay if you use them, and get renewal terms in writing.
PostHog Cloud usage fees
PostHog Cloud is metered per product, and the first 1 million analytics events are free every month according to PostHog's pricing page. Costs above that allowance depend on the products in use, the retention you select and the number of projects, with a Pay-as-you-go plan raising the project and retention limits. Model your event volume per product, not as one total, and confirm which hosting region you need, since US and EU Cloud are priced from the same page.
Self-hosted server and storage
A self-hosted PostHog hobby deployment runs on infrastructure you pay for directly, and PostHog recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage. Storage grows with event volume and retention, and the bill recurs monthly for compute, disks and backups. Confirm the sizing for your expected volume, because PostHog's README says open-source deployments should scale to approximately 100k events per month before moving to Cloud.
Engineering time for upgrades and backups
Running PostHog yourself means someone maintains the stack, applies upgrades, tests restores and watches disk growth. This is recurring labor, usually the largest hidden cost, and it is paid as internal salary or a retainer with an outside team. Ask any implementation partner to state in the scope who owns upgrades, backup testing and restore drills, and how often each is performed.
Monitoring and on-call
Self-hosted analytics becomes production infrastructure once dashboards or product decisions depend on it. You need uptime and ingestion monitoring, alerting and an on-call rota, which recur as staff time and tooling. PostHog's self-host documentation states that self-hosted deployments are officially unsupported and that PostHog does not offer customer support on them, so every incident response falls to your team or to a provider you contract.
Migration project effort
Moving from Amplitude is a one-time project covering API credentials, historical imports, event name remapping, identify and group events, duplicate avoidance and SDK changes. PostHog's managed migrations import at most one year of data per direct job, so long history takes several jobs and planning. Ask for a written scope that lists which dashboards, cohorts and experiments are rebuilt, since that rework is often the largest part of this one-time cost.
Paid licensing for ee features
The MIT-licensed core of PostHog is free to self-host, but premium features in the ee directory need a PostHog license on self-hosted instances. If you need SSO, audit logs or custom roles, budget for that license as a separate recurring cost, or use the posthog-foss repository and accept its missing features. Ask PostHog which features your requirements depend on and whether those sit in ee before you commit to a design.
What moving from Amplitude to PostHog involves
The sequence turns a set of Amplitude events, users and dashboards into PostHog data and reports, with checks at each stage so nothing is imported twice or lost by surprise. Most of the work is in planning identities and event names, not in the import itself.
Inventory events, properties and retained history
List the events, user and group properties, cohorts and dashboards you rely on in Amplitude, and note how far back your history goes. Confirm which raw data you can export and which decisions depend on it. The output is a short written inventory that engineering and analytics both sign off on, since it defines what the migration must reproduce.
Confirm plan access and API credentials
Check with PostHog that your plan includes the import features, because the migration documentation states that a paid product analytics plan is required to unlock them. Create Amplitude API credentials with read access to the project you are moving. The output is a confirmed plan and a working credential that you have tested outside the import job.
Plan identify and group events
Decide how Amplitude user IDs and device IDs map to PostHog distinct IDs, and how account or organization records map to groups. Identify and group events are what let historical activity attach to the right person or company in PostHog. The output is a written identity map reviewed by the team that owns user data, including how anonymous sessions are linked after sign-in.
Remap event names and properties
Compare Amplitude event and property names with the names your PostHog SDK instrumentation will send, and write a mapping table for every rename, merge or dropped property. Funnels and cohorts built on old names will break if this is skipped. The output is a mapping file that the import configuration and the new tracking plan both follow.
Run imports in windows that avoid duplicates
Plan each direct import job around the limit of one year of data per job, and keep the windows non-overlapping because events are not deduplicated. Run a small test window first and count events in both systems for the same period. The output is a per-window log showing job ID, date range and event counts, which proves that no range was imported twice.
Switch SDKs in parallel with existing tracking
Add the PostHog SDK alongside Amplitude in the product, sending the events from the mapping table, and keep Amplitude running until the new data matches. Running both during this period lets you compare behavior without a gap in reporting. The output is a release where both SDKs fire and a documented date on which Amplitude tracking is removed.
Validate dashboards, funnels and cohorts
Rebuild the key funnels, retention charts and cohorts in PostHog, then compare them with the Amplitude versions over an overlapping period. Investigate every difference until the cause is known, whether it is a mapping gap, a timezone setting or a sampling choice. The output is a sign-off record for each dashboard that stakeholders have accepted.
Accept that imported events cannot be selectively deleted
Before the import, confirm with the data owner which events and time ranges are meant to be loaded, because the migration documentation states there is no way to selectively delete event data once imported. Mistakes can only be fixed by restructuring the project, so keep the test imports separate. The output is an approved import scope that the team has agreed in writing.
Questions buyers ask before choosing PostHog or Amplitude
What does it cost to move from Amplitude to PostHog?
The cost splits into three parts: PostHog's fees, the people doing the work, and the infrastructure if you self-host. On PostHog Cloud, the first 1 million analytics events are free every month, and the managed migration import is free of ingestion fees when sent with the historical_migration flag. A paid product analytics plan is still required to unlock the import features, so confirm that line item with PostHog before you plan the budget. Engineering time for SDK changes, event mapping and validation is usually the largest cost, and it is one-time. Ask any implementation partner for a quote built from a written scope that lists the event volume, the number of projects and the dashboards to rebuild.
How long does an Amplitude to PostHog migration take?
No duration is fixed by the vendor documentation, so the timeline depends on what you have to move. The main drivers are the number of event types and identify and group calls that need remapping, how many years of history you want, the number of SDK integrations across web and mobile apps, and how many dashboards, cohorts and experiments must be rebuilt by hand. Each direct import job covers at most one year of data, so multi-year histories need several jobs run in sequence. Events are not deduplicated, so you should plan a clean sequence and test with a small window first. Ask for a phased plan with a validation step before the cutover date.
Can our internal team run the migration without outside help?
Often yes, if you have engineers who know your event taxonomy and at least one person who owns analytics definitions. The managed migration uses API credentials for Amplitude and PostHog, so no custom export pipeline is strictly needed for the direct path. Teams usually need help where the work is hard to reverse: confirming event names and properties, deciding which history is worth importing, switching SDKs across releases, and checking that funnels and retention match before anyone retires Amplitude. Because there is no way to selectively delete imported event data, a review gate before each import job matters. A fixed-scope engagement can cover only the parts you choose to hand over.
Is the PostHog self-hosted hobby deployment safe for production?
PostHog's 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. The free Docker Compose hobby deployment is installed with a deploy-hobby script, and PostHog recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage. The README also says open-source deployments should scale to approximately 100k events per month, and recommends moving to PostHog Cloud above that. Before using it for production analytics, you need your own operations, backup, patching and on-call owners. DeployOpen can plan, harden, back up and support a self-hosted platform inside your infrastructure under a written scope.
When is PostHog Cloud EU the better choice?
PostHog Cloud EU is usually the better choice when you want managed hosting in the European Union without running the platform yourself, and when your volume is above the scale the open-source README describes. PostHog's pricing page lists two Cloud hosting regions, US (Virginia) and EU (Frankfurt). The Free plan includes 1 project and 1-year data retention, and the Pay-as-you-go plan raises this to 6 projects and 7-year retention. SSO, audit logs, custom roles and project permissions are sold as platform packages, so check whether you need them. Confirm the hosting region, retention period and sub-processor terms in writing with PostHog before you sign.
What happens to history older than one year in Amplitude?
Each direct import job from Amplitude covers at most one year of data, so older history needs additional jobs or a different path. PostHog's managed migrations also accept JSONL files from an S3 bucket, which is the route to plan for longer archives, and the Amplitude export is the source for that file set. Confirm with PostHog how far back your plan retains imported data, since the Free plan keeps 1 year and paid plans keep 7 years. Keep the raw export in your own storage as an archive, because imported event data cannot be selectively deleted once it is in PostHog.
Is PostHog's open-source license enough for our use?
The PostHog repository is MIT licensed, but content in its ee directory has a separate license, and premium features from that directory on a self-hosted instance require a PostHog license. If you need fully free software, PostHog points teams to the posthog-foss repository, which is purged of all proprietary code and features, so some product features may not be present there. Have legal review the ee/LICENSE terms against the features you plan to use. Licensing is a separate question from support, which PostHog does not provide for self-hosted instances.
How DeployOpen helps you evaluate and move to PostHog
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms in your own infrastructure. For Amplitude vs PostHog, we help you test whether PostHog covers your funnel, retention, cohort and experiment needs before you commit to a deployment model.
How we scope
- We map the Amplitude charts, cohorts, experiments and dashboards your teams rely on to the PostHog features that replace them.
- We size event volume, retention needs and data residency requirements, and confirm the PostHog Cloud region or self-hosted option you need.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- We set up the PostHog environment in your chosen location and configure SDKs, identify calls and event naming conventions.
- We run a managed migration test on a limited historical window, checking for duplicate imports and remapped event names.
- We test feature flags, session replay settings and consent handling against the privacy requirements your legal team has set.
How we hand over
- We deliver written documentation covering configuration, data flows, event dictionaries and the known gaps versus Amplitude.
- We walk your analysts and engineers through dashboards, cohorts and experiment setup so the team can operate the platform.
- We provide evidence and records that your internal auditors or assessors can review, while they remain responsible for any formal opinion.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover version upgrades, backups, monitoring and periodic checks of the analytics pipeline.
- Ask us to confirm the support scope in writing, since PostHog does not provide customer support for self-hosted instances.
