Amplitude cost vs self-hosted PostHog

Is self-hosted PostHog cheaper than Amplitude for our event volume?

Self-hosting PostHog is cheaper than Amplitude only when your event volume is small and your team can run the platform without vendor support. It moves cost from the Amplitude invoice to servers, engineering hours and the operational risk of running an unsupported product. The answer depends on your event volume, on how many events you would be sending each month, and on whether you already have people who can operate Docker Compose, backups, upgrades and security patches. The cost components are different on each side. With Amplitude, you pay the vendor under your contract, and the price is driven by the plan and the metric your contract uses, so take the figures from your own order form or a fresh quote rather than from a public list, since this page does not state Amplitude's prices. With self-hosted PostHog, the hobby deployment is free under the MIT license, but you pay for the server, storage, backups and the staff time to run it. PostHog's self-host documentation recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage as a starting point. The README says open-source deployments should scale to approximately 100k events per month and recommends PostHog Cloud above that, so beyond that level the hosting bill and operating load grow quickly. The other side of the comparison is support. PostHog's self-host documentation states that self-hosted deployments are officially unsupported and that PostHog does not offer customer support on them, so any outage, upgrade failure or data incident falls to your own team. PostHog Cloud includes the first 1 million analytics events free each month, which covers many small and mid-sized programs without any invoice. Before deciding, ask Amplitude for a written estimate for your monthly events and, for PostHog, model your expected events against the 1 million Cloud allowance and the roughly 100k self-hosting guidance, then add the staff hours your platform team can commit to on-call and upgrades.

Which cost components change between Amplitude and PostHog

This table sets each cost component of Amplitude against the matching component of a self-hosted PostHog deployment, and marks whether it is one-time or recurring. Read it as a checklist for a quote or a budget conversation, because the largest differences sit in events or MTUs, support and internal skills rather than in license fees.

Cost component	Amplitude (commercial)	Self-hosted PostHog	One-time or recurring
Subscription or license	Plan fees set by the contract, with tier limits on events or MTUs. Confirm the current terms in your order form.	MIT-licensed core carries no license fee. Premium features in the ee directory need a PostHog license on a self-hosted instance.	Amplitude: recurring. PostHog: recurring only if you buy the ee license.
Event or MTU fees	Usage charges scale with events or monthly tracked users. Ask how overage and MTU counting work before you commit.	PostHog Cloud bills usage above its free monthly allowance of 1 million analytics events (PostHog pricing page). Self-hosting has no per-event vendor fee.	Recurring. Volume is the main driver for both options.
Hosting infrastructure	None. Amplitude runs the service.	The hobby Docker Compose stack recommends a server equivalent to 4 vCPU, 16 GB RAM and more than 30 GB of storage (PostHog self-host docs). You pay for compute, storage and backups.	Recurring for PostHog, scaling with event volume.
Implementation	Instrumentation and SDK work, plus any warehouse or export setup. Scope depends on your event taxonomy.	Deployment, SDK changes, event mapping and hardening. A fixed-scope engagement can cover this, with the scope agreed in writing first.	One-time for most of the work, with ongoing changes.
Historical migration	Export of raw events is typically needed before leaving. Check the Export API limits in your contract.	Managed imports from Amplitude carry no ingestion fee when sent with the historical_migration flag. A paid product analytics plan is still required to unlock import features, and each direct import covers at most one year of data.	One-time.
Support	Included in your plan according to its support terms. Confirm the response times in writing.	PostHog states self-hosted deployments are officially unsupported and it does not provide customer support for them. Support must come from your team or a partner retainer.	Amplitude: recurring within the subscription. PostHog: recurring if you buy a retainer.
Upgrades and maintenance	Handled by the vendor as part of the service.	Your team or a partner applies upgrades, patches and backups. Plan for regular upgrade windows and test restores.	Recurring.
Internal skills	Analysts and product teams need Amplitude knowledge. Little infrastructure expertise is required.	Someone must operate Docker, databases, storage and monitoring, and own incident response. This is a recurring staffing cost that is easy to underestimate.	Recurring.

What moves the comparison up or down

Six drivers decide whether self-hosted PostHog stays cheap or becomes the expensive option. Several interact, so a team with high event volume and no platform staff can face a very different bill than a small EU team with a clear retention need.

Monthly event volume

Self-hosted PostHog is documented as scaling to approximately 100k events per month, and PostHog recommends moving to PostHog Cloud above that. PostHog Cloud includes the first 1 million analytics events free every month, so volume is the main trigger. Estimate your monthly event count from the Amplitude export or current MTU reports, then compare it with both thresholds before you assume either option is cheapest.

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 data retention. If your analysts need multi-year cohort history or several products tracked separately, the cloud tier may be the only option that matches the Amplitude setup without custom work. Confirm how many projects and how much history you need before you model costs.

Licensing scope for premium features

The core PostHog code is MIT licensed, but the ee directory covers premium features on self-hosted instances and needs a PostHog license. If you need SSO, audit logs, custom roles or project permissions, those are sold as platform packages, so the self-hosted total cost includes a license you must negotiate. Ask PostHog exactly which features your roles and audit requirements depend on before you commit to self-hosting.

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 them. Your team therefore carries upgrades, backups, scaling and incident response for the event pipeline, which can run as a 24/7 analytics dependency for product decisions. Decide who responds when ingestion stops, and whether a paid support or implementation retainer must cover that gap.

EU hosting requirement

PostHog Cloud offers two hosting regions, US (Virginia) and EU (Frankfurt), so an EU data residency need can be met without running servers. Self-hosting keeps data wherever you place the servers, which gives full control but moves the hosting, patching and access controls into your scope. Check with your data protection team whether a US-run cloud region is acceptable, because that answer determines whether self-hosting is a compliance choice or a cost choice.

In-house platform skills

The hobby deployment is a Docker Compose setup, but PostHog recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage, and the Kubernetes option for new paid self-hosted installs is no longer supported. Teams with container, database and observability skills can run it at a lower recurring cost. Teams without them should price an external operator, because staff time or retainer fees often outweigh the server bill.

How the cost picture differs by deployment option

Staying on Amplitude means your analytics bill is a subscription to Amplitude's commercial plans, which are metered on events or monthly tracked users depending on the plan you hold. You pay Amplitude for the platform, the data retention and the features your plan unlocks, and your internal team pays for instrumentation, dashboards and governance. The recurring cost moves with your usage, so growth in traffic, new products and additional tracked identities all raise the invoice at renewal.

Recurring subscription: the license fee renews each term and rises as event or user volume grows, so the cost is ongoing rather than one-time.
Internal labor: your own engineers and analysts maintain tracking plans, while Amplitude handles hosting, uptime and the vendor's own support tiers.
Data export costs: moving raw events out for a warehouse or a migration can require higher plan tiers or additional engineering time to build exports.
Pricing changes: a new plan structure or metric change can shift cost without any change in your own usage.
Lock-in effects: years of dashboards, cohorts and SDK integrations raise the internal effort of any later move.

Ask Amplitude in writing which metric your current plan uses, which features and export options are included, and how overages are billed before comparing totals.

How to build the cost model with your own numbers

This sequence turns your Amplitude invoices and usage history into a side-by-side model with PostHog, so you can see at what event volume each option gets expensive and when to revisit the decision. It produces one spreadsheet that your finance, data and platform owners can all check.

Export twelve months of event and MTU counts
Pull monthly event volumes and monthly tracked users (MTUs) for the last twelve months from Amplitude's usage reporting, and cross-check the totals against the invoices your finance team has paid. Record the counts by product, environment and event type, because different events may be billed or counted differently. You are done when every month has a figure that matches an invoice line, and you can state the peak month and the average month separately.
Map plan thresholds and overage terms
Take the current order form and any amendments, then write down the included volume, the MTU or event tier, the overage rate, the billing period and the notice terms for changes. Ask your Amplitude account team to confirm in writing how each overage is calculated and whether unused allowance carries over. You are done when a single table shows, for each month, what you paid and what the contract would have charged at a different tier.
Size the PostHog option against your volumes
Compare your monthly event counts with the points PostHog publishes: its pricing page lists a first 1 million analytics events free each month on the Free plan, and its README says open-source deployments should scale to approximately 100k events per month before moving to PostHog Cloud. If you are considering self-hosting, size the server against the guidance in PostHog's self-host documentation (4 vCPU, 16 GB RAM and more than 30 GB of storage for the hobby deployment) and add the infrastructure and staff costs for that machine. You are done when you have a line for each option at your peak month and your average month.
Price staff time for operations and upgrades
Estimate the hours your platform and data engineers will spend on upgrades, backups, monitoring, security patches, SDK changes and incident response, then multiply by your own internal hourly rates. Note that PostHog states self-hosted deployments are unsupported and that it does not provide customer support for infrastructure questions, so any support you need must come from your team or a partner such as DeployOpen under a written scope. You are done when the staff cost is a recurring line in the model with a named owner for each task.
Add migration effort per import job
Count the historical data you want to bring over. PostHog's managed migration imports up to one year of data per direct job from Amplitude, and events are not deduplicated, so overlapping date ranges will create duplicates. Plan one import job per year of history, and add the time to remap event names, generate identify and group events, and test dashboards against the source. You are done when each job has a date range, an owner and a validation check, and the total is a one-time cost in the model.
Set a break-even review date
Plot your monthly event growth against the cost lines from the previous steps and identify the event volume at which the self-hosted option, the PostHog Cloud usage bill, or staying with Amplitude becomes the cheapest. Set a review date in your planning calendar and agree the trigger, such as crossing a volume you have modeled, that reopens the decision. You are done when the break-even point, the trigger and the reviewer are written down and signed off by finance and the data owner.
Request written quotes and confirm current pricing
Ask Amplitude for a written renewal quote that states the tier, included volume, overage rate, MTU definition, data retention, export limits and any fees for the export or data residency options you need. Ask PostHog to confirm in writing the current usage prices for events, session replay and other products you plan to use, the platform package cost for SSO and audit logs if you need them, and the cloud region you will use. Pricing changes often, so treat the figures you collected as a snapshot and re-check them before any decision. You are done when both quotes sit next to the model and every line traces back to a document.

Costs teams forget on each side

Both options carry costs that do not appear on a price comparison. Amplitude's costs tend to grow with usage and surface at renewal, while self-hosted PostHog moves operational responsibility, backups and licensing decisions onto your team.

Renewal and overage exposure

Amplitude's bill follows usage measures such as events or monthly tracked users, so a plan that fits today can grow expensive as products, SDKs and user bases expand. Ask your account team in writing how overage is billed, how the measure is counted, and what happens to pricing at renewal. Model growth on your own event volumes before signing, since a contract sized for current usage can leave little room for change.

Raw export before any move

Historical raw events are the asset that makes a later migration possible, and they are easiest to export while the subscription is active. Confirm which export methods your plan allows, how long exports take at your volume, and where the files will be stored. Budget storage and engineering time for those files, because the export is a cost you pay before any saving from leaving.

Unsupported status and operations staffing

PostHog states that self-hosted deployments are officially unsupported and that it does not offer customer support for product, infrastructure or other questions on self-hosted instances. Your own engineers, or a contracted operations partner, carry upgrades, incident response and on-call work. Estimate those hours as a recurring cost and decide who owns them before you choose the hobby deployment.

Backups and restore testing

A self-hosted analytics store holds event history that you cannot easily rebuild, so backup schedules, retention of those backups and storage capacity become your responsibility. A backup that has never been restored is not evidence of recovery. Schedule restore tests into the operating plan and record the time they take, since that result, not the backup job log, tells you what recovery will cost.

Duplicate events from historical imports

PostHog's direct imports from Amplitude cover at most one year of data per job, and events are not deduplicated. Running overlapping jobs, or re-running a job after a failure, can double-count history in your reports. Plan one import window per period, agree on a naming and flag convention for migrated events, and check counts against Amplitude before you retire the old source.

Enterprise licensing for premium features

PostHog's core code is MIT licensed, but features in the ee directory need a PostHog license on a self-hosted instance. If you need SSO, audit logs or custom roles, confirm which of them sit in ee and what license they require before you design access controls. Alternatively, confirm whether the posthog-foss repository covers your needs, since it is purged of proprietary code and features.

What a migration from Amplitude costs in effort

The effort of moving from Amplitude to PostHog is driven less by the tooling than by the decisions around historical data. PostHog's managed migration connects with Amplitude API credentials or with JSONL files staged in an S3 bucket, and each direct import job covers at most one year of data. Confirm early which credentials your team can issue, how many years of history you need to keep, and how many import jobs that implies. Events are not deduplicated, so re-running a job over the same window will create duplicate events. Keep a record of each job's date range before you start the next one.

Plan the event model before the first import. Amplitude's identify and group events need to be generated so that user properties and account-level grouping survive in PostHog, and event names often need remapping so that dashboards built on the old names keep working. The imported events cannot be selectively deleted once they are in the project, so run every test import against a staging project first and validate counts, funnels and retention against Amplitude's own reports before you touch production. The import features also require a paid product analytics plan, so confirm that licensing with PostHog before the test run, not after it.

Historical data is the most common reason these migrations stall. Teams often reach the point where the new SDK is live but the one-year-per-job import has not been scoped, and the old and new tools end up running in parallel for months. Parallel running has a cost on both sides: you keep paying Amplitude for events you are still sending, and you pay for ingestion in PostHog for the same traffic, while analysts split their reporting between two tools. Set a cutover date for the SDK switch, decide which historical windows are essential for compliance or board reporting, and treat the rest as optional. Ask your implementation partner to put that schedule in writing with the scope.

Questions buyers ask about PostHog and Amplitude costs

Is self-hosting PostHog free?

The MIT-licensed core carries no license fee, but self-hosting is not free to run. You pay for the server, storage, backups, monitoring, upgrades and the engineering time to keep them working. PostHog's self-host documentation describes a 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. Those are one-time setup costs plus recurring infrastructure and staff time. Note that PostHog states self-hosted deployments are officially unsupported, so the support you would normally buy from a vendor is not part of the bill. Ask your team to cost each of these components separately.

Can our own team run a self-hosted PostHog deployment?

It depends on whether you already run containerized services in production with on-call coverage, backups and tested restores. The hobby deployment is a Docker Compose stack, which is a manageable starting point for a platform team, but event ingestion, storage growth, upgrades and the data pipeline all need ownership. Since PostHog does not provide customer support for infrastructure questions on self-hosted instances, the people who answer incidents must be your own staff or a partner. Check whether you have someone who can own upgrades and capacity planning over time, not just the first install.

How long does a migration from Amplitude take?

The duration depends mainly on how much history you import, how many event names need remapping, and how many SDK integrations you switch. PostHog's managed migrations can import historical events directly from Amplitude using API credentials, but each direct import job covers at most one year of data, and events are not deduplicated. So a multi-year history means several jobs, and avoiding duplicates requires planning. Scope also includes generating identify and group events, updating tracking code and validating dashboards. No duration is set by the product itself, so ask any partner for a written plan with the volume of history and the number of integrations listed.

When does PostHog Cloud make more sense than self-hosting?

PostHog Cloud usually makes more sense when you want vendor-run infrastructure, support and regional hosting without operating the stack yourself. PostHog's pricing page lists US (Virginia) and EU (Frankfurt) regions, a Free plan with the first 1 million analytics events free every month and 1-year data retention, and a Pay-as-you-go plan with 6 projects and 7-year retention. SSO, audit logs, custom roles and project permissions are sold as platform packages. The self-hosted hobby path becomes harder to justify when you need support, long retention, or access controls that depend on paid features. Compare the Cloud usage bill for your expected volume against the full self-hosted cost.

What does the 100k events per month guidance mean for us?

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 the vendor's stated planning threshold, not a hard limit or a guarantee of performance. Your actual capacity depends on hardware, event size, query patterns and retention. If your monthly volume is near or above this figure, or growing quickly, ask for a load test on your own sizing before committing to a self-hosted design. Also confirm how your volume compares with the 1 million free monthly events on PostHog Cloud.

Do the premium ee features need a PostHog license?

Yes, if you run self-hosted instances and want premium features from the ee directory. PostHog's LICENSE file covers the ee/ directory under a separate license, and its README states that using those features on a self-hosted instance requires a PostHog license. Teams that need fully free software can use the posthog-foss repository, which PostHog describes as purged of all proprietary code and features. Before you plan, list the features you need, such as SSO or audit logs, and confirm whether each sits in ee or in the free code. Get the license position in writing from PostHog or your legal team.

What should a written quote from an implementation partner include?

A useful quote lists the scope and the cost components separately, so you can compare it with your internal estimate. Ask for the target deployment (hobby or otherwise), sizing assumptions, the historical data volume and how it will be split across import jobs, the event names and identify or group events to remap, and the SDKs to switch. Require a statement of what is one-time (installation, migration, validation) and what recurs (hosting, upgrades, monitoring, retainer support). Ask how backups and restores are tested, what happens to Amplitude data after export, and who holds the PostHog relationship. DeployOpen works on a fixed scope agreed in writing before work starts, with a quote following from that scope, and it does not publish prices.

Does the Amplitude export path affect migration cost?

Yes. The cost of moving history depends on how cleanly you can get it out of Amplitude and into PostHog. PostHog's managed migration uses your Amplitude API credentials for direct import, or accepts JSONL files in an S3 bucket, so the export route you choose changes the preparation work. Also note that PostHog's documentation says there is no way to selectively delete event data once imported, so test with a sample before running full jobs. Ask your partner to document the export route, the file format and the validation steps before any import starts.

What to confirm with Amplitude and PostHog before you decide

Before you choose between staying on Amplitude and moving to PostHog, get the current terms of both in writing. For Amplitude, ask for the plan that covers your product analytics seats and monthly tracked users or events, the overage rules that apply when you go past your allowance, how the contract renews, and what happens to your data if you downgrade or leave. Ask whether the data residency options you need, including an EU endpoint if your data must stay in Europe, are included in the plan you are quoted or sold separately. Do not rely on a price you saw in an older document. Ask for the figures as they apply to your own event volume and user counts.

For PostHog, confirm the current pricing page figures against your projected volume, because the free monthly allowance, retention periods and project limits differ by plan. Ask which PostHog Cloud region fits your data residency requirement, since PostHog lists US (Virginia) and EU (Frankfurt) hosting. Then ask what SSO, audit logs, custom roles and project permissions will cost as platform packages, because many enterprise access controls are not in the base plan. Also confirm whether your event mix relies on features in the ee directory. If it does, a PostHog license is needed on a self-hosted instance, and you should ask PostHog for that license terms in writing before you plan around the open-source core alone.

Decide the support level you need before you choose the self-hosted option. PostHog's self-hosted hobby deployment is officially unsupported, and PostHog does not offer customer support for product, infrastructure or other questions on self-hosted instances. That means upgrades, backups, scaling, security patches and incident response are your responsibility, or the responsibility of a contracted party you name in writing. If your team cannot cover that work internally, agree on who operates the stack, who responds at 2 a.m., and how the budget for that person or partner is approved, before comparing the license-free server cost to a paid cloud plan.

How DeployOpen scopes a fixed-price PostHog implementation

DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For Amplitude cost vs self-hosted PostHog, most engagements are fixed-scope, so the cost comparison, deployment choice and migration plan are agreed in writing before any work starts.

How we scope

Inventory current Amplitude plan, monthly event volume and MTU counts before choosing a deployment model.
Define which PostHog products are in scope, such as product analytics, session replay, flags or experiments.
Agree in writing whether the target is PostHog Cloud region, self-hosted hobby, or a supported self-hosted build.

How we build

Deploy PostHog on infrastructure in your own cloud account, sized to the event volumes agreed in the scope.
Configure SSO, access roles, backups and retention settings to match your data residency and audit requirements.
Test event ingestion, dashboards and migration jobs in a staging environment before any production traffic moves.

How we hand over

Document architecture, sizing assumptions, upgrade steps and the cost components your team will pay for each year.
Record the migration runbook, including credential handling, historical import batches and duplicate-event checks.
Deliver the written configuration, test evidence and access list so your team can operate the platform independently.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer, priced from the written scope.
Plan upgrades and security patches against the PostHog release cycle you confirm with your team.
Review event volumes and infrastructure load periodically so cost forecasts stay accurate as usage grows.