Google Analytics vs PostHog: when each one fits
A product-led team that needs funnels, session replay and web analytics in one place is weighing GA4 against PostHog, and the decision turns on a few concrete facts rather than brand preference. GA4 still fits when attribution is tied to Google Ads, when reporting is led by marketing and built around standard reports, and when the organization has no appetite for operating a data stack. PostHog fits when product analytics and web analytics should share one event model, when raw event ownership matters for later analysis, and when hosting in the EU is required. PostHog Cloud EU, hosted in Frankfurt, is the option most regulated teams will evaluate first, because the self-hosted route is a different commitment.
Three questions settle most of the choice. The first is monthly event volume: the PostHog README says open-source deployments should scale to approximately 100k events per month and recommends moving to PostHog Cloud above that, so a team already past that level should price Cloud before anything else. The second is data residency: confirm with your legal and privacy owners whether analytics data may leave your jurisdiction, and whether the EU-US Data Privacy Framework covers your transfers or whether EU hosting is required outright. The third is operating capacity: a self-hosted PostHog instance is officially unsupported, and PostHog does not provide customer support for infrastructure questions on it, so the team must own upgrades, backups and capacity planning itself.
Before deciding, run a short test. Export one month of GA4 events, count them against the 100k ceiling, and list which dashboards depend on Google Ads data. Then check which features the team needs from the ee directory, since premium self-hosted features require a PostHog license, and confirm the cost of Cloud tiers and any platform packages directly with PostHog. Document the answers in writing so the choice can be revisited if traffic grows.
Which option fits which scenario
This table maps common product team situations to the better fit between Google Analytics 4 and PostHog, with the reason for each. Read each row against your own event volume, residency rules and tooling, and treat any row marked as needing confirmation as a question to settle with PostHog or your own environment before committing.
| Scenario | Better fit | Reason |
|---|---|---|
| Under 100k events a month, with an engineer to spare | Self-hosted PostHog hobby deployment | The README says open-source deployments should scale to about 100k events a month, and the hobby install is free under MIT. Upgrades and fixes fall to your team because PostHog does not support self-hosted instances. |
| Above 100k events a month | PostHog Cloud or a paid self-hosted plan, to be confirmed | PostHog recommends moving to Cloud above the open-source ceiling. Ask PostHog which hosting option fits your volume and whether a paid self-hosted license is needed. |
| Strict EU data residency | PostHog Cloud EU (Frankfurt), subject to your review | Cloud hosting offers an EU region in Frankfurt. Confirm with PostHog and your legal team that the region, sub-processors and transfer terms meet your requirements. |
| Data must stay on your own servers | Self-hosted PostHog hobby deployment, if volume allows | Only self-hosting keeps data on your infrastructure. Check the hobby ceiling and confirm which ee features you need, since premium features on self-hosted instances require a PostHog license. |
| Google Ads attribution is central to reporting | Google Analytics 4 | GA4 is built around Google's advertising products. PostHog does not replace Google Ads attribution, so confirm which conversion data you need to keep flowing. |
| Session replay, funnels and product analytics needed together | PostHog | PostHog's product list covers product analytics, session replay and surveys in one tool, which removes the need to stitch separate vendors together. |
| Free event tier is the deciding factor | PostHog Cloud free tier, to be confirmed | PostHog's pricing page lists the first 1 million analytics events as free each month, with 1 project and 1-year retention on the Free plan. Confirm current limits, since your event mix and ee features may change the cost. |
| Premium features such as SSO or audit logs are required | Confirm before choosing | PostHog sells SSO, audit logs, custom roles and project permissions as platform packages. Ask for a written quote for the features you need on your chosen deployment. |
How PostHog's ee license split affects a self-hosted replacement
PostHog's core repository is MIT licensed, but its ee directory is not. The PostHog repository states that the code outside ee/ is covered by the MIT Expat license, while content in ee/ falls under a separate license file. The PostHog README adds that using premium features from the ee directory on a self-hosted instance requires a PostHog license. Before committing, check the feature list against that boundary: the README groups the product into product analytics, web analytics, session replay, error tracking, logs, feature flags, experiments, surveys, data pipelines and AI, and each of these may have a premium component. Ask PostHog, in writing, which of the features your team needs sit in ee/ and what license terms apply to them on a self-hosted instance.
A team that needs fully free software should not assume every feature it wants is available under the open license. PostHog points these teams to the posthog-foss repository, which the README describes as purged of all proprietary code and features. Treat that repository as a different product scope: run a test deployment from it, confirm that the analytics, replay and flag workflows your product team depends on work there, and document any gaps before the rest of the plan depends on them. Also confirm whether the hobby Docker Compose deployment described in PostHog's self-host documentation is built from the same code path your license review covers, since the license answer for one may not carry over to the other.
Plan the license review as a standing item, not a one-time check. PostHog's self-hosted deployments are officially unsupported and PostHog does not provide customer support for product or infrastructure questions on them, so any ee feature you adopt is a dependency your team must support itself or pay a third party to support. Record the license file version you reviewed, the features you are using from ee/, and who in your organization owns the decision to upgrade. Reviewing these points with your legal counsel and procurement team before a pilot keeps the license question from surfacing late in a migration.
Google Analytics vs PostHog capability by capability
This table sets GA4 against PostHog across web analytics, product analytics, session replay, experiments, data pipelines, retention, export and licensing. Where the researched facts do not settle a capability on one side, the cell tells you what to confirm with the vendor. Read the licensing and retention rows first, because they decide whether the self-hosted route is viable for your team.
| Capability | Google Analytics 4 | PostHog |
|---|---|---|
| Web analytics | Standard GA4 web reporting on Google-hosted infrastructure, with reports and explorations configured in the GA4 interface | Web analytics is a listed product in the PostHog README, available on PostHog Cloud and on self-hosted deployments |
| Product analytics | Event-based analysis is available, but depth depends on the GA4 configuration and retention settings you choose | Product analytics is a listed product in the PostHog README, sharing one event store with web analytics |
| Session replay | Not part of GA4; teams pair it with a separate recording tool | Session replay is a listed product in the PostHog README; confirm the replay features and limits on your plan and deployment |
| Feature flags and experiments | Experiments run through Google Optimize's successor tooling and GA4 audiences; confirm current availability with Google | Feature flags and experiments are listed products in the PostHog README; confirm which features sit in the ee directory |
| Surveys and data pipelines | Data leaves GA4 through BigQuery export and the Data API rather than a pipeline product | Surveys and data pipelines are listed in the PostHog README; confirm their availability on self-hosted hobby installs |
| Data retention | Set in GA4 property settings; this caps explorations, not standard reports, so confirm the limits for your property | Set by plan: the pricing page lists 1-year retention on the Free plan and 7-year retention on Pay-as-you-go |
| Data export | Exports go through the BigQuery export and the Data API; see the export page for daily caps and token quotas | Historical import is documented from Mixpanel, Amplitude and Google Analytics via BigQuery; confirm the export options you need |
| Licensing | Proprietary hosted service with no self-hosted option | MIT for most of the repository; the ee directory needs a PostHog license for premium features on self-hosted instances |
| Hosting regions | Google-operated regions; confirm data location settings against your EU residency requirement | PostHog Cloud offers US (Virginia) and EU (Frankfurt) regions; self-hosting places data in your own infrastructure |
Where the data lives and who controls it
The choice between GA4, PostHog Cloud and a self-hosted PostHog deployment decides who holds the event data, which legal rules apply to transfers and consent, and who administers access. Each card below covers one of those decisions and what to confirm before you commit.
GA4 hosted by Google
GA4 runs on Google's infrastructure, and your raw event data reaches you mainly through the BigQuery export. Standard properties carry daily export limits, so the export is the route out and needs to be set up and tested before you rely on it. Check which GA4 export type your property supports, how long you keep the exported tables, and who in your team owns the BigQuery project and its billing.
PostHog Cloud in two regions
PostHog Cloud is offered in a US (Virginia) region and an EU (Frankfurt) region, so you choose where events are stored at signup. The EU region keeps the data in the EU, but your vendor still operates the service, so confirm the processing locations, subprocessors and contract terms in writing. Choosing the region late is hard to undo, so decide it with your legal and privacy teams first.
Self-hosted hobby deployment
A self-hosted PostHog hobby deployment runs in your own cloud account or data center, so event data never leaves infrastructure you control. You take on hosting, patching, backups and upgrades, and PostHog states that self-hosted deployments are officially unsupported. Ask whether your team can staff that operating work, and treat the stated scale limit as a hard boundary for sizing.
EU-US Data Privacy Framework
The European Commission adopted its adequacy decision 2023/1795 on July 10, 2023, allowing personal data to flow from the EU to US companies that participate in the Data Privacy Framework. It does not settle every transfer question: it applies only to certified recipients, so confirm that your vendor is certified, and it does not remove the need for contracts, transfer impact checks and clear records. A self-hosted deployment in the EU avoids the transfer question for that data.
CNIL and the consent exemption
CNIL's guidance says most large audience measurement offerings fall outside the consent exemption regardless of how they are configured. That matters if you run PostHog for web analytics in France or other EU markets, because product and session features often need consent. Plan for a consent banner for PostHog unless your own configuration and counsel show otherwise, and confirm the exemption conditions before you rely on them.
SSO and roles as paid packages
PostHog sells SSO, audit logs, custom roles and project permissions as platform packages, so access control on Cloud depends on your plan. Without those packages, you may have fewer options to connect staff accounts to your identity provider, limit who sees session recordings, or prove who changed a configuration. Map your required access controls against the plan before the migration, and decide how self-hosted accounts will be provisioned and removed.
What each option costs to run and what drives it up
GA4 has no license fee, so its cost sits in the surrounding work: exports, warehouse storage and the consent tooling a team may still need. PostHog costs differ by deployment, from a usage-priced cloud account to a self-hosted server you operate yourself. The cards below separate the recurring items from the one-time ones so you can ask for a quote that compares like with like.
GA4 recurring export and warehouse costs
GA4 itself is free to use, but teams that need raw data usually pay for the BigQuery export and the storage and queries that run on it. Those charges are billed by Google Cloud, not by Google Analytics, so they will not appear on the GA4 interface. Ask who owns the Google Cloud project, which datasets are exported and how long they are kept, and whether anyone has modeled query volume for the reports you plan to run after a switch.
Consent tooling you may still need
Moving to a cookieless or consent-exempt tool does not automatically remove the consent banner, because other trackers on the site may still require it. Consent management platforms are usually a separate recurring subscription. Confirm which marketing and advertising tags remain on the site after the switch, and whether the analytics tool itself still needs to sit behind the banner under CNIL's conditions or under your own legal advice.
PostHog Cloud usage-based pricing
PostHog Cloud charges by usage, and the pricing page states that the first 1 million analytics events are free every month. The Free plan includes 1 project and 1-year data retention, while the Pay-as-you-go plan raises this to 6 projects and 7-year data retention. SSO, audit logs, custom roles and project permissions are sold as platform packages. Ask for a quote built from your expected monthly events, projects, retention period and whether you need the EU (Frankfurt) region.
Self-hosted server and operations
The hobby Docker Compose deployment is free under the MIT license, but PostHog recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage. You pay for that infrastructure, plus the time to run upgrades, backups, monitoring and on-call response. PostHog states that self-hosted deployments are officially unsupported, so the operating work falls on your team or on a partner you contract. Ask who owns patching, restore testing and capacity planning, and what happens when event volume passes the roughly 100k events per month ceiling.
PostHog license for ee features
The ee directory is covered by a separate license, and premium features used on a self-hosted instance require a PostHog license. This is a recurring commercial cost that only applies if you need those features, so check which ones your team depends on before assuming the self-hosted build is free. If you want fully free software, the posthog-foss repository removes all proprietary code, which changes what features are available. Ask for the license price in writing and the list of ee features it unlocks.
One-time migration and rebuild work
Moving off GA4 has one-time costs that recur only once: exporting history, mapping GA event names such as page_view to PostHog events, rebuilding dashboards and funnels, and replacing the gtag snippet with PostHog tracking. PostHog's documented route for GA4 runs through the BigQuery export, and historical imports from Mixpanel or Amplitude are limited to one year per job. Ask the vendor or partner to list each tracking change, each dashboard to rebuild and the parallel run period before cutover.
Questions to ask in a quote
Ask every bidder to price the same inputs: monthly events, projects, retention period, data region, number of sites or apps, and whether session replay and feature flags are in scope. Request the recurring items (hosting, BigQuery, licenses, consent tools, on-call) separately from one-time items (migration, rebuild, training). Confirm who handles upgrades and security patches, what support you receive on self-hosted instances, and how the scope changes if event volume grows beyond your initial estimate.
What a move from Google Analytics to PostHog involves
The sequence moves GA4 measurement into PostHog in a controlled order, so reporting continuity, hosting choices and license limits are settled before the old tag is removed.
Inventory GA4 events, reports and users
Your analytics owner lists every GA4 event, custom dimension, conversion and standard report that the business uses, and marks which ones feed dashboards, paid media or other tools. Ask who relies on each report and whether it depends on Google Signals, audiences or Google Ads links that PostHog will not replicate. The step is done when each item has a named owner and a keep, rebuild or drop decision.
Decide hosting and the license boundary
Choose between PostHog Cloud in the EU (Frankfurt) or US (Virginia) regions, and a self-hosted deployment. If you self-host, decide whether the MIT-licensed hobby deployment fits your volume, since PostHog's README says open-source deployments should scale to about 100k events per month, or whether you need the ee directory, which requires a PostHog license. Confirm the license terms and self-host support position directly with PostHog before committing. The output is a written hosting decision with its license basis.
Export GA4 history through the BigQuery route
If you need historical data, follow PostHog's documented Google Analytics migration path, which runs through the GA4 BigQuery export. Standard GA4 properties have a daily export limit, so confirm the export is enabled and that the history you need has been captured before the Google side changes. Check the row counts and date range in BigQuery against GA4 reports so you know what was taken out. Note that imported history may not carry raw-event features, and that PostHog does not offer selective deletion of imported event data once it is loaded.
Map GA event names to PostHog events
Build a mapping table from GA4 event names such as page_view to PostHog event names, properties and person properties, and decide which GA parameters become event properties. Agree naming conventions with the teams that own dashboards so the same action is not counted under two names. The output is a reviewed mapping file, and each mapped event has been checked against a test session in both tools.
Replace the gtag snippet with PostHog
Developers remove the gtag or Google Tag Manager tags from the site or app and install the PostHog snippet or SDK, then send the mapped events. Test in a staging environment with consent handling in place, since the consent rules that apply to GA4 also apply to PostHog cookies and identifiers. The step is complete when test traffic appears in PostHog with the expected event names, properties and page views.
Run both tools in parallel
Keep GA4 and PostHog receiving the same traffic for a period you set with your stakeholders, and compare totals, funnels and key conversions between them. Expect differences in definitions, session logic and bot filtering, and document each one rather than forcing the numbers to match. Confirm that dashboards, alerts and data consumers in your warehouse have been repointed where needed.
Cut over and retire the old tracking
Once the parallel comparison is signed off, switch reporting to PostHog, stop sending GA4 events and archive the GA4 exports you need for audit or reference. Remove unused GA tags and update your privacy notice and consent records to name the new processor. The output is a closed cutover record listing what moved, what was dropped and where historical data now lives.
Google Analytics vs PostHog cost and effort questions
Can our team run the PostHog hobby deployment ourselves?
Your team can install it, but the question is whether it can operate it for the long term. PostHog's self-host documentation offers a free Docker Compose deployment under the MIT license, installed with a deploy-hobby script. The documentation recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage. Installation is the smaller job. Ongoing work includes patching, backups, monitoring, upgrades and capacity planning, and that work recurs for as long as you run the instance. Ask whether your engineers have time for that load every month, not just at launch.
What does the work require from our internal team?
Expect to supply infrastructure, an accountable owner and engineers who can run containers and databases. Your side typically provides the cloud or data center account, network access, DNS and TLS, identity for administrators, and decisions on which events to collect. Someone must also own the tracking code in your website and product, because PostHog's self-hosted route still requires SDK integration in every property. Confirm these responsibilities in writing before work starts, since they determine whether the project stays inside your current staffing.
How long does a migration take, and what sets that time?
The duration depends on the number of properties, the volume of historical data you need, and how much of your GA4 setup is rebuilt rather than copied. The documented Google Analytics route runs through the GA4 BigQuery export, and each step (exporting, mapping event names, rebuilding funnels and dashboards, replacing the gtag snippet) adds work. Historical imports also have limits: PostHog's direct imports from Mixpanel or Amplitude cover at most one year per job, and events are not deduplicated. No duration is set by this page. Ask any implementation partner for a written timeline tied to a fixed scope.
Does PostHog Cloud EU remove the self-hosting effort?
Yes, it removes the infrastructure operation, but it changes the cost model and the control model. PostHog's pricing page lists two Cloud hosting regions, US (Virginia) and EU (Frankfurt), and states that the first 1 million analytics events are free every month. The Free plan includes 1 project and 1-year data retention, while the Pay-as-you-go plan raises this to 6 projects and 7-year retention. Costs then scale with event volume and plan features. You still own the tracking implementation, governance and data decisions. Compare the Cloud EU option against your self-hosted run cost before deciding.
What does the ee license mean for the features we plan to use?
The PostHog repository is MIT licensed except for the ee directory, which has a separate license in ee/LICENSE. The README states that premium features from ee require a PostHog license on a self-hosted instance. If your roadmap depends on those features, licensing becomes a cost line and a legal review item. Teams that need fully free software can use the posthog-foss repository, which is purged of all proprietary code and features, but that version lacks the premium features. Map each required feature to its license file before you commit to a design.
Does self-hosting PostHog come with vendor support?
No. PostHog's self-host documentation states that self-hosted deployments are officially unsupported and that PostHog does not offer customer support for product, infrastructure or other questions on self-hosted instances. That shifts troubleshooting, security patching and upgrade testing to your team or to a partner you contract separately. The same documentation notes that new Kubernetes deployments of the paid self-hosted product are no longer supported. Budget for an internal on-call rota or a retainer for ongoing support, and make sure the contract names who responds to incidents.
When should we move from the hobby deployment to 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. Use this as the trigger for a capacity review, not a rough sizing rule. Measure your current monthly event count across all properties, include growth from planned campaigns and new product features, and decide before traffic spikes. A migration under pressure costs more than one planned in advance. Ask your partner to include the threshold and the move path in the written scope.
How DeployOpen helps teams evaluate and implement PostHog
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Google Analytics vs PostHog, we start with a written scope that tests whether self-hosting PostHog fits your event volumes, licensing needs and data residency rules before any build begins.
How we scope
- Written scope that states which PostHog products, event sources and regions the engagement covers
- Event volume and license review of the ee directory features your team needs on a self-hosted instance
- Decision record comparing self-hosted PostHog, PostHog Cloud EU and staying on GA4 for your case
How we build
- Deployment of the self-hosted stack in your infrastructure, with sizing checked against your actual event load
- Configuration of the tracking snippet, event naming map and consent settings agreed in the scope
- Security testing of the deployment and its ingestion endpoints before any production traffic is sent
How we hand over
- Runbooks for installation, upgrades, backups and restores, written for your own platform team
- Documented event schema, data retention settings and access roles so your team can audit them
- Evidence pack of configuration and test results that your compliance team or auditors can review
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
- Ongoing upgrades, backup checks and continuous testing are available as a retainer
- Quote follows from the written scope; confirm support terms for your environment when you request one
