Hotjar vs PostHog: when each fits and what the decision turns on
A Hotjar renewal or the Contentsquare move forces a decision, and the answer depends on what you need from one tool. Hotjar fits teams that want a managed heatmap and recording tool inside Contentsquare, while PostHog fits teams that want heatmaps, session replay, surveys, product analytics and feature flags in one product under their own control. Hotjar no longer accepts new accounts, so the real choice is whether to move to a Contentsquare plan or leave for a self-hosted option. Four factors should drive the decision. The first is volume: PostHog's README says open-source deployments should scale to approximately 100k events per month and recommends PostHog Cloud above that, so estimate your monthly events and sessions before sizing anything. The second is data residency: PostHog Cloud offers US (Virginia) and EU (Frankfurt) regions, while self-hosting keeps data in your own infrastructure. The third is operating capacity, since PostHog states that self-hosted deployments are officially unsupported and that it offers no customer support for them. The fourth is scope: if you need product analytics, feature flags or experiments beyond Hotjar's heatmaps and recordings, PostHog covers more ground.
If you choose self-hosting, confirm the licensing before you commit. PostHog is MIT licensed except for the ee directory, and premium features there need a PostHog license on a self-hosted instance. If you need fully free software, the posthog-foss repository is purged of proprietary code and features, so check that the features you rely on exist there. Ask PostHog which edition and license terms apply to your planned feature set, and get the answer in writing. For cost, compare the self-hosted server and your staff time against PostHog Cloud's usage pricing at your projected volume, and remember that the first 1 million analytics events per month are free on Cloud, according to PostHog's pricing page.
Which option fits which scenario
This table matches common team profiles to the better fit between Hotjar's successor path, PostHog Cloud and self-hosted PostHog. Read each row against your own residency needs, event volume and platform engineering capacity, then check the reason column against the points you must confirm before committing.
| Team profile | Better fit | Reason |
|---|---|---|
| Existing Hotjar user who wants no infrastructure | PostHog Cloud | Nothing to run or patch. Confirm with PostHog which heatmap and replay features your plan includes, since Hotjar recordings do not carry over. |
| EU team with strict residency needs | PostHog Cloud (EU) or self-hosted PostHog | PostHog Cloud offers an EU (Frankfurt) region. If policy requires data to stay on your own servers, self-hosting is the stronger fit, but plan for your own operations. |
| Team that wants product analytics and flags alongside heatmaps | PostHog (Cloud or self-hosted) | PostHog's README groups product analytics, session replay, feature flags and surveys in one product, so one tracking setup covers several needs. |
| Low-volume team with platform engineering capacity | Self-hosted PostHog (MIT core) | The README says open-source deployments should scale to about 100k events per month. Self-hosting suits this profile if you can run Docker Compose or Kubernetes and handle your own support. |
| High-volume team above the 100k events guidance | PostHog Cloud | PostHog recommends migrating to Cloud above roughly 100k events per month. Self-hosted instances are officially unsupported, so sustained load is a risk to plan for. |
| Team needing vendor support for self-hosted operations | PostHog Cloud or a paid support arrangement | PostHog states it does not offer customer support for self-hosted product or infrastructure questions. Ask an implementation partner or your own team to cover this gap. |
| Team that must avoid any ee directory features | Self-hosted posthog-foss | PostHog says premium ee features need a license on self-hosted instances. The posthog-foss repository is purged of proprietary code, so confirm which features it still includes. |
What each tool records and why it matters for privacy
Heatmaps, recordings and events capture different things, and each one carries a different privacy exposure. Heatmaps aggregate clicks, scrolls and cursor movement per page. Session recordings replay the DOM and interactions for individual visits, so they can expose anything a visitor sees or types unless masking is applied. Event tracking records named actions with properties you define in code, which makes it the most controllable of the three. Before you compare Hotjar and PostHog feature by feature, list which of these three data types your team actually needs and which fields each one would touch, including form inputs, URLs with query strings and account identifiers.
Masking is where the configuration decisions sit. Confirm in your own environment which elements are masked by default in each tool, which are excluded by CSS selector or attribute, and whether text inside inputs is captured at all. Check how PostHog's session replay masking settings and any input or text masking options behave on your pages, and test them on a staging site with dummy personal data. Keep a written record of the masking rules and who approved them, because the rules will need to change when your pages change.
The consent question is separate from masking. The CNIL's sheet 16 sets out conditions under which analytics trackers can be exempt from consent, and those conditions are narrow: audience measurement and A/B testing only, a single publisher scope, no cross-checking with other processing, truncated IP addresses and a tracker lifetime of at most 13 months. CNIL also states that most large audience measurement offerings fall outside the exemption regardless of configuration. Session replay and heatmaps are usually not described in that sheet as exempt uses, so treat any recording tool as likely requiring consent until your data protection lead or counsel confirms otherwise. Ask your DPO to review the CNIL analytics guidance against the exact tracker set you plan to deploy.
Where your session data lives under each option
Session recordings, heatmap data and survey responses contain user behavior and often personal data, so the hosting location decides who processes them. The cards below cover the PostHog Cloud regions, self-hosting, Hotjar's position inside Contentsquare, transfer rules, identity packaging and the evidence you need to prepare.
PostHog Cloud regions
PostHog Cloud offers two hosting regions, US (Virginia) and EU (Frankfurt). Choosing the region sets where your project's events and replay data are stored, so make the choice before you install the snippet, because moving data later is not something the supplied information covers. Ask PostHog in writing which region your project uses, where backups and support access are located, and which sub-processors touch the data. Confirm the choice against your own data residency requirement.
Self-hosting on your own servers
With self-hosted PostHog, recordings, heatmap inputs and survey answers stay on servers you control, whether in your data center, your cloud account or an air-gapped network. You become responsible for the database, backups, patching, access logs and the retention settings. PostHog's self-host documentation states that self-hosted deployments are officially unsupported and that PostHog does not provide customer support for these instances, so the operating work must be covered by your team or a partner.
Hotjar's status inside Contentsquare
Hotjar is now part of Contentsquare, and Hotjar's site states that new Hotjar accounts can no longer be created. Existing users sign in to Contentsquare, so the processor, contract and data location for current Hotjar data are governed by that relationship. Ask Contentsquare for the data processing terms that apply to your account, where Hotjar recordings are stored, and whether features or retention may change. Do not assume the terms you accepted with Hotjar still apply unchanged.
EU-US Data Privacy Framework transfers
The European Commission adopted its adequacy decision for the EU-US Data Privacy Framework on July 10, 2023 (decision 2023/1795). Under it, personal data can flow from the EU to US companies that participate in the framework. If you choose PostHog Cloud US, verify that the vendor's entity is listed as a participant and keep that check in your transfer records. The decision does not remove the need for a documented transfer assessment, and it does not cover EU hosting choices you may need to make for other reasons.
SSO and identity on PostHog Cloud
On PostHog Cloud, SSO, audit logs, custom roles and project permissions are sold as platform packages rather than included on every plan. Who can view recordings of real users is a data access question, so these controls matter as much as hosting location. Confirm which package includes SSO and role-based access, whether audit logs cover replay viewing and export, and how access is removed when staff leave. Self-hosting shifts identity setup to your own identity provider and access configuration.
Compliance evidence you must prepare
Hosting location does not make a deployment compliant by itself. You need records of the processing purpose, the lawful basis or consent flow, masking settings for inputs and sensitive pages, retention periods, access reviews and transfer assessments. Auditors and regulators will ask for this evidence regardless of vendor. DeployOpen can prepare systems, controls and evidence for an assessment, but independent auditors issue any opinion or certification, and the vendor's own certificates should be requested directly from it.
PostHog's license split and what the free path covers
The core of the PostHog repository is under the MIT Expat license, but the content in the ee/ directory is covered by a separate license in ee/LICENSE. For a self-hosted instance, premium features from `ee/` require a PostHog license. Before you commit to a design, check the license file and list which features your teams actually need, then map each one to whether it sits in the MIT core or in ee/. Ask PostHog to confirm in writing which features are covered by a paid license on self-hosted instances, since that boundary determines your licensing cost.
If your policy requires fully free software, the posthog-foss repository is the relevant path. The PostHog README describes it as purged of all proprietary code and features, so it is the version to evaluate against a no-proprietary-components requirement. The trade-off is straightforward: the foss path carries no license fee, but you give up the premium features in ee/, and any gap in analytics, replay, surveys or flags must be covered by your own build or by a different tool. Confirm with your security and legal teams which build your policy permits before the pilot starts, not after.
For evaluation, PostHog's self-host documentation describes a free Docker Compose hobby deployment under the MIT license, installed with a deploy-hobby script. The documentation recommends a server with the equivalent of 4 vCPU, 16 GB of RAM and more than 30 GB of storage. Treat this as a test environment: PostHog states that self-hosted deployments are officially unsupported and that it offers no customer support for self-hosted product or infrastructure questions. The README also says open-source deployments should scale to approximately 100k events per month before you move to PostHog Cloud, so size your pilot traffic against that threshold.
What Hotjar and self-hosted PostHog actually cost to run
Hotjar is now part of Contentsquare, and new Hotjar accounts can no longer be created, so the cost question for existing users is a contract question. Plans sold through Contentsquare are described as session-based in some cases and per-product in others, and the terms that set the bill are not something a public page can settle. Treat the plan as a document you must obtain in writing, not as a number you can estimate from a website.
- Session volume: Ask how sessions are counted, what happens when you exceed the included volume, and whether overage is billed in arrears or blocked.
- Per-product scope: Confirm which products (heatmaps, recordings, surveys, or Contentsquare analytics) are included, and whether adding one changes the base fee.
- Retention: Ask how long recordings and heatmap data are kept, and whether longer retention is an add-on.
- Term and renewal: Confirm the contract length, notice period for non-renewal, and any price change clause at renewal.
- Export: Ask what you can export at termination, in what format, and whether the export is free.
Before you sign anything, check these terms against your expected traffic and the features your team uses every week.
PostHog Cloud is usage-based and recurring. The first 1 million analytics events each month are free, and the Free plan includes 1 project and 1-year data retention. The Pay-as-you-go plan raises this to 6 projects and 7-year data retention, so the cost driver is both event volume and how long you need to keep data. Cloud is offered in US (Virginia) and EU (Frankfurt) regions, and the region choice is set when you start.
- Free tier: 1 project, 1-year retention, first 1 million analytics events each month at no charge.
- Pay-as-you-go: 6 projects and 7-year retention, billed on usage above the free allowance.
- Platform packages: SSO, audit logs, custom roles and project permissions are sold as platform packages, not included in the usage tiers.
- Historical imports: Imports from Mixpanel or Amplitude require a paid product analytics plan, and a direct import job covers at most one year of data.
- Region: Confirm whether your data residency requirement fits US (Virginia) or EU (Frankfurt) before you create the project.
Check the current pricing page for per-event rates and any package prices, because these change and are not restated here.
Self-hosted PostHog has no license fee for the MIT-licensed core, but the infrastructure and people to run it are your costs. PostHog recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage for its free Docker Compose hobby deployment, and it says open-source deployments should scale to approximately 100k events per month before moving to Cloud. Premium features from the ee directory need a PostHog license, and PostHog does not offer support for product, infrastructure or other questions on self-hosted instances.
- Server: A recurring cloud or hardware cost. Sizing rises with event volume and replay volume, so plan for growth.
- Storage growth: Session replay and event data accumulate every month. Storage is usually the cost that grows fastest, and it recurs.
- Backups and upgrades: You pay for backup storage, restore testing and the staff time to apply upgrades. These are recurring.
- Monitoring and on-call: Uptime alerts, disk and database monitoring, and an owner for incidents. These fall to your team or a partner you contract.
- Support: PostHog does not provide support on self-hosted instances, so budget for internal engineering or a retained partner.
Ask any implementation partner for a fixed-scope quote that lists setup, masking rules, backup testing and the retainer for upgrades separately.
The costs fall into two groups. One-time costs are incurred at setup and migration: installing the instance, building masking rules, rebuilding heatmaps and surveys, swapping the tracking snippet and running both tools for a short overlap. Recurring costs continue for as long as you run the stack: hosting, storage, backups, upgrades, monitoring and staff time. For a Cloud deployment, the recurring cost is the usage bill. For a self-hosted deployment, it is infrastructure plus people.
- One-time setup: Installation, configuration, masking rules, tracking changes and testing.
- One-time migration: Historical data from Hotjar does not carry over, so budget for rebuilding dashboards and surveys rather than importing them.
- Recurring infrastructure: Compute, storage and network costs, which grow with event and replay volume.
- Recurring operations: Upgrades, backups, security patches and on-call coverage.
- Cost drivers: Retention length, event volume, replay length, number of projects and how often you upgrade.
Ask each vendor and partner to split their quote into one-time and recurring lines so you can compare the two models over the same period.
Cost moves with a small set of variables. For Hotjar and Contentsquare, the contract terms set the bill, and for PostHog Cloud the event count and retention set it. For self-hosting, the infrastructure and staff time set it. Changing one variable, such as retention or event volume, can change the total more than the choice of platform itself, so model these variables before you compare headline figures.
- Volume: Sessions, events and replays. Ask each vendor for its counting method before comparing.
- Retention: Longer retention raises storage on self-hosted systems and may require a higher Cloud tier.
- Compliance scope: Data residency, consent handling and audit logging can require platform packages or extra engineering.
- Team skills: Teams without operations experience will pay more in staff time, or in an external retainer, to run a self-hosted stack.
- Change rate: Frequent product changes increase masking, tracking and survey rework.
Write these variables into your cost model with your own traffic figures, then request quotes on the same assumptions.
Operating effort for a self-hosted PostHog deployment
Self-hosting PostHog moves operations to your team. The key point for planning is that the reader's own staff, not PostHog, own upgrades, backups, scaling and incident response for the instance. 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. Any support you need has to come from your own engineers, a partner or community channels, so you should decide that before cutover rather than during an outage.
Map the ownership before you install anything. Your platform team needs to own the host or hosts, the Docker Compose or other deployment layer, database and storage backups and restore tests, version upgrades and the process for reviewing release notes, capacity growth as session replay and event volume rise, and on-call response for ingestion gaps. Also confirm who maintains the tracking snippet and the masking rules for session replay, since a wrong masking setting is a privacy issue, not only an uptime issue. The PostHog README says open-source deployments should scale to approximately 100k events per month and recommends PostHog Cloud above that, so ask your team to forecast volume from your current Hotjar session counts before choosing a path.
Two platform facts affect the plan. First, new Kubernetes deployments of the paid self-hosted product are no longer supported, so confirm which deployment method your architecture team will use and whether the free Docker Compose path meets your needs. Second, the hobby setup is installed with a deploy-hobby script under the MIT license, and PostHog recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage as a starting point. Check that sizing against your own traffic and retention plan. DeployOpen can plan, implement, harden, back up, upgrade and document the deployment for you under a fixed-scope agreement, with scope, deliverables and timelines agreed in writing before work starts, or under a retainer for ongoing upgrades and support. Ask for those items explicitly in the written scope.
How a move from Hotjar to PostHog is structured
The sequence turns Hotjar heatmaps, recordings and surveys into a PostHog setup you run or rent, with a clear record of what was rebuilt, what was left behind and when the old tool is switched off.
Inventory heatmaps, recordings and surveys
Export a list of every Hotjar site, heatmap, recording filter, survey and feedback widget in use, and note which pages, owners and business reviews depend on each one. Record which event names and page URLs the reports rely on, since these become the reference for the rebuild. Check whether anything in the list has an export path, because Hotjar's own export options may be limited and Contentsquare sets the terms for existing users. The output is a signed-off inventory that names the features you intend to keep, so nobody is surprised later.
Decide between PostHog Cloud and self-hosting
Choose where the PostHog data will live before anything is built. PostHog Cloud is offered in a US (Virginia) region and an EU (Frankfurt) region, and its pricing page lists the free event allowance and retention by plan. The self-hosted Docker Compose hobby deployment is MIT licensed, but PostHog states that self-hosted deployments are officially unsupported and that it does not provide customer support for them. The README also recommends moving to PostHog Cloud above roughly 100k events per month. Confirm with your security and data protection teams where recordings may be stored, then document the decision and its owner in writing.
Rebuild masking and privacy rules first
Before any recording is captured, define which fields, inputs and page areas must be masked and which pages must not be recorded at all. Write these rules as configuration in PostHog, then test them on staging pages that contain forms, payment details and personal data. Review the rules against your consent setup, since recordings and heatmaps may fall outside the audience measurement exemption that CNIL describes for analytics. The output is a masking test report that a reviewer has approved, with the pages that remain excluded listed explicitly.
Rebuild heatmaps, funnels and surveys
Recreate each inventoried heatmap as a PostHog view, using the same page URLs and event definitions where possible. Rebuild surveys in PostHog's survey feature, with the same triggers, targeting and questions, and check that the responses reach the dashboards your team uses. Where Hotjar reports depended on other tools, decide whether PostHog's product analytics, feature flags or experiments replace them or whether they stay where they are. The output is a side-by-side checklist showing each Hotjar item, its PostHog equivalent and the owner who signed it off.
Confirm which history can be imported
Ask PostHog in writing which import paths apply to Hotjar data. PostHog's managed migrations cover historical events from Mixpanel and Amplitude, and its documented scripted migrations cover Google Analytics and Heap, but the researched facts do not show a managed path for Hotjar recordings or heatmaps. Plan on the basis that historical Hotjar recordings and heatmaps will not carry over, and keep an archive or a read-only Hotjar export only if one is available to you. The output is a short written statement of what is preserved, what is archived and what is lost, approved by the business owner.
Swap the tracking snippet in staging
Replace the Hotjar snippet with the PostHog snippet in a staging environment, then load each key template, form and logged-in flow. Confirm that pages load without errors, that consent behavior matches the rules from the masking step, and that events arrive in PostHog with the expected names and properties. Remove the Hotjar snippet from the staging copy so that two tools do not record the same session. The output is a test log with the pages checked and the defects closed.
Run both tools during a short overlap
Deploy the PostHog snippet to production while Hotjar is still active for a short, agreed overlap period. Compare recording counts, heatmap coverage and survey response volumes between the two tools, and investigate gaps caused by masking, sampling or consent. Keep the overlap short and fixed in the plan, because recording two tools on the same visitors adds privacy and performance risk. The output is a comparison note that either confirms parity for the inventoried features or lists the exceptions to resolve before switch-off.
Switch off Hotjar and document the cutover
Remove the Hotjar snippet from production, cancel or stop the Hotjar subscription in line with your contract terms, and confirm that no tag manager still loads it. Record the cutover date, the final export or archive location, the owner of the PostHog configuration and the support route you have chosen, since self-hosted PostHog has no vendor support. For more detail on the import and rebuild work, see the migration page under this hub. The output is a cutover record that the security and data protection owners have signed.
Questions buyers ask before choosing PostHog over Hotjar
What does it cost to run PostHog compared with Hotjar?
Hotjar is a subscription you pay Contentsquare for, while self-hosted PostHog moves the cost to infrastructure and people. The PostHog README says open-source deployments should scale to approximately 100k events per month, and PostHog's self-host docs recommend a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage as a starting point. Recurring costs include the server, storage, backups, monitoring and staff time for upgrades. One-time costs include planning, tracker installation, masking rules and rebuilding surveys and heatmaps. Replay storage grows with traffic and retention, so ask for a sizing estimate based on your own page views and session volume before comparing totals.
How long does a move from Hotjar to PostHog take?
The duration depends on how many sites and pages you track, how many surveys and heatmaps you must rebuild, and how much masking work your privacy team requires. Plan for a short overlap period in which both tools run, so you can compare recordings and survey response rates before cutting over. Any timeline should come from a written scope that lists sites, tracked events, surveys and environments. Ask your implementation partner to show the work items behind each milestone rather than accepting a single date.
What does my team need to provide for the work?
Expect to supply access to the target cloud account or data center, a named owner for DNS and TLS certificates, and someone who can approve the tracking snippet changes on each site. Product owners need to decide which events, funnels and surveys matter, and privacy or legal staff should sign off on the masking rules and retention period. Your engineers will need to review the tracking code in your single-page applications and mobile apps. Confirm these responsibilities in the written scope so that nothing stalls during the overlap.
Can our own team run PostHog self-hosted without outside help?
Yes, it is possible for a capable platform team, but the work is ongoing rather than a single installation. The free Docker Compose hobby deployment is MIT licensed and installed with a deploy-hobby script, yet 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 team would own upgrades, backups, scaling and incident response. Also note that the ee directory needs a PostHog license for premium features, so check which features you need before choosing a path.
Is PostHog Cloud or self-hosting the better fit above 100k events per month?
PostHog's README recommends moving to PostHog Cloud above roughly 100k events per month for open-source deployments, so volume alone often points toward Cloud. Self-hosting still makes sense when data residency, contractual control or a no-vendor-hosting rule outweighs the operating effort. PostHog Cloud offers US (Virginia) and EU (Frankfurt) regions, and its pricing page says the first 1 million analytics events are free every month. Compare Cloud usage costs against your own infrastructure and staff costs, and confirm regional and retention terms in writing.
Do historical Hotjar recordings and heatmaps carry over to PostHog?
Generally no. Hotjar recordings and heatmaps are not part of the historical import paths PostHog documents, which cover event data from tools such as Mixpanel, Amplitude, Google Analytics and Heap. Plan to keep Hotjar data exported or archived under your own retention rules before the account closes, and treat PostHog as a fresh collection starting from cutover. Confirm the export options available from your Hotjar or Contentsquare account, since features and access may change at Contentsquare's discretion.
What masking must be configured before going live?
Before go-live, define which form fields, text elements and input types are masked or excluded from session replay, and test those rules on real pages with dummy data. Decide what your consent banner must signal, and document the retention period you configure. Your privacy and legal teams should approve the list, and engineers should verify that masking holds after each front-end release. For EU visitors, CNIL's analytics guidance says most large audience measurement offerings do not fall within the consent exemption regardless of configuration, so ask counsel how session recordings fit your consent model.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Hotjar vs PostHog, that means first agreeing what PostHog must replace, then building and handing over a deployment your team can operate.
How we scope
- We confirm which Hotjar features matter most: heatmaps, recordings, surveys and funnels.
- We record in writing whether you need PostHog Cloud or a self-hosted deployment, and why.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We size and install PostHog in your environment and set up session replay masking rules.
- We rebuild heatmaps, surveys and event tracking, and test that recordings respect masking.
- We document the tracking snippet swap and plan a short overlap period with Hotjar.
How we hand over
- We deliver runbooks for installation, backup, upgrades and access control for your team.
- We document consent configuration and the evidence your privacy reviewers may ask for.
- We walk your engineers through the deployment so they can operate it without us.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer.
- Retainers can cover PostHog version upgrades and periodic security testing of the tracking setup.
- Confirm with us in the written scope which support tasks sit inside a retainer and which are extra.
