PostHog vs Matomo: Which Should You Self-Host?

Quick Verdict

These are different tools for different jobs. Matomo wins for web analytics — pageviews, referrers, bounce rates, goal tracking. It is a direct Google Analytics replacement that has been stable since 2007 and runs on two containers with modest resources. PostHog wins for product analytics — session replays, feature flags, A/B testing, funnel analysis, user surveys. If you are building a SaaS product and need to understand user behavior inside your app, PostHog is the tool. If you run a website and want to know where traffic comes from, use Matomo.

Updated March 2026: Verified with latest Docker images and configurations.

Overview

PostHog is an open-source product analytics platform built with Django and backed by ClickHouse. It bundles event tracking, session replays, feature flags, A/B experiments, surveys, and a data warehouse into one stack. It targets product teams at software companies. The self-hosted “hobby” deployment runs 12+ services including PostgreSQL, ClickHouse, Kafka (Redpanda), Redis, MinIO, and Temporal. Official site | GitHub

Matomo (formerly Piwik) is a full-featured web analytics platform built with PHP and backed by MariaDB/MySQL. It tracks pageviews, referrers, goals, funnels, e-commerce conversions, and custom dimensions. It has been actively developed since 2007 and is the most mature self-hosted analytics tool available. The Docker deployment runs two containers. Official site | GitHub

Feature Comparison

Feature	PostHog	Matomo
Primary use case	Product analytics	Web analytics
Event tracking	Yes (autocapture + custom)	Yes (custom events, goals)
Pageview tracking	Yes	Yes
Session replays	Yes (built-in)	Yes (paid plugin)
Feature flags	Yes (built-in)	No
A/B testing	Yes (built-in)	Yes (paid plugin)
Funnels	Yes	Yes
User surveys	Yes (built-in)	No
Heatmaps	Yes	Yes (paid plugin)
E-commerce tracking	Limited	Yes (full)
Google Analytics import	No	Yes
Tag manager	No	Yes (built-in)
Custom reports	Yes (SQL-based)	Yes (GUI-based)
API	Yes (REST + GraphQL)	Yes (Reporting API)
Cookie-free tracking	Yes	Yes (configurable)
GDPR consent required	Configurable	Depends on config
Real-time dashboard	Yes	Yes
Database	ClickHouse + PostgreSQL	MariaDB/MySQL
License	MIT (hobby)	GPL v3
Active development	Very active (weekly releases)	Active (monthly releases)

Installation Complexity

PostHog

PostHog’s self-hosted deployment is heavy. The official hobby setup runs 12+ containers: the Django web app, a Celery worker, a Node.js plugin server, Rust capture services, PostgreSQL 15, Redis 7, ClickHouse, Kafka (Redpanda), Zookeeper, MinIO, Temporal, and a Caddy reverse proxy. The recommended approach is the official deploy script:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/posthog/posthog/HEAD/bin/deploy-hobby)"

The script generates environment variables, downloads multiple Compose files, and starts everything. You cannot reasonably maintain this stack by hand — the Compose file references base configs, environment variable substitution, and inter-service dependencies that the script manages.

Minimum hardware: 4 vCPUs, 8 GB RAM (16 GB recommended), 30 GB disk. This is a serious resource commitment for a single analytics tool.

For the full setup walkthrough, see How to Self-Host PostHog.

Matomo

Matomo runs on two containers: the PHP application and MariaDB. Setup is straightforward.

Create a docker-compose.yml:

services:
  matomo:
    image: matomo:5.8.0-apache
    container_name: matomo
    restart: unless-stopped
    ports:
      - "8080:80"
    environment:
      MATOMO_DATABASE_HOST: matomo-db
      MATOMO_DATABASE_USERNAME: matomo
      MATOMO_DATABASE_PASSWORD: change-this-strong-password
      MATOMO_DATABASE_DBNAME: matomo
    volumes:
      - matomo-data:/var/www/html
    networks:
      - matomo-net
    depends_on:
      matomo-db:
        condition: service_healthy
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost/matomo.php"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 60s

  matomo-db:
    image: mariadb:11.4.10
    container_name: matomo-db
    restart: unless-stopped
    environment:
      MARIADB_ROOT_PASSWORD: change-this-root-password
      MARIADB_DATABASE: matomo
      MARIADB_USER: matomo
      MARIADB_PASSWORD: change-this-strong-password
    volumes:
      - matomo-db-data:/var/lib/mysql
    networks:
      - matomo-net
    healthcheck:
      test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
      interval: 30s
      timeout: 10s
      retries: 5
      start_period: 30s

volumes:
  matomo-data:
    driver: local
  matomo-db-data:
    driver: local

networks:
  matomo-net:
    driver: bridge

Start it:

docker compose up -d

Then open http://your-server:8080 and follow the setup wizard. Matomo also needs a cron job for report archiving — see the full Matomo setup guide for details.

Minimum hardware: 1 vCPU, 2 GB RAM (4 GB recommended), 10 GB disk. Matomo runs comfortably on a $5/month VPS.

Winner: Matomo. Two containers versus twelve-plus. A readable Compose file versus a deploy script you have to trust. A quarter of the RAM. Matomo is dramatically simpler to deploy and maintain.

Performance and Resource Usage

Resource	PostHog (hobby)	Matomo
Containers	12+	2
RAM (idle)	4-6 GB	300-500 MB
RAM (recommended)	16 GB	2-4 GB
CPU (minimum)	4 vCPUs	1 vCPU
Disk (base install)	~10 GB	~500 MB
Disk growth	Fast (ClickHouse event storage)	Moderate (MariaDB)
Tracking script size	~80 KB (JS SDK)	~22 KB
Event throughput (hobby)	~100K events/month	Millions of pageviews/month

PostHog’s ClickHouse backend is optimized for analytical queries on large event datasets, but the entire stack is resource-hungry. The hobby deployment is explicitly limited to around 100,000 events per month. Beyond that, PostHog recommends their cloud offering or significant manual tuning.

Matomo handles high-traffic sites on modest hardware because its MariaDB backend is well-optimized for the query patterns web analytics produces. The cron-based archiving system pre-computes reports, so dashboard loads are fast even with millions of rows.

Community and Support

PostHog has an active community on GitHub (~25K stars), a public Slack, and extensive documentation. The company is well-funded and ships updates weekly. However, self-hosted support is explicitly limited — PostHog does not offer paid support plans for self-hosted instances and recommends their cloud product for production use.

Matomo has been around since 2007 (originally Piwik) and has a mature ecosystem. ~20K GitHub stars, an active forum, hundreds of plugins (both free and paid), and commercial support plans through Matomo’s parent company. The plugin marketplace covers heatmaps, session recording, A/B testing, funnels, and more — though many premium features require paid plugins.

Both projects are well-documented. PostHog’s docs are developer-focused with strong API documentation. Matomo’s docs are broader, covering everything from basic setup to enterprise GDPR compliance workflows.

Use Cases

Choose PostHog If…

• You are building a SaaS product and need to understand how users interact with your app
• You need session replays to watch users navigate your UI
• You want feature flags and A/B testing in the same tool as your analytics
• Your team is developer-heavy and comfortable with a complex stack
• You have 16+ GB of RAM available for a single analytics tool
• Your event volume stays under 100K/month (hobby deployment limit)

Choose Matomo If…

• You need a Google Analytics replacement for one or more websites
• You care about pageviews, traffic sources, bounce rates, and conversions
• You want a simple two-container Docker deployment
• You need to import your existing Google Analytics history
• You run on limited hardware (2-4 GB RAM is plenty)
• You need GDPR compliance with clear documentation and consent workflows
• You want a plugin ecosystem for features like heatmaps or e-commerce tracking

Final Verdict

PostHog and Matomo solve fundamentally different problems. Comparing them head-to-head is like comparing a CRM to a spreadsheet — they overlap in narrow ways, but their core value propositions are different.

For web analytics — tracking website traffic, understanding where visitors come from, measuring content performance — Matomo is the clear choice. It is lighter, simpler to deploy, battle-tested over nearly two decades, and purpose-built for exactly this job. It replaces Google Analytics with feature parity and full data ownership.

For product analytics — understanding how users interact with your software product, running experiments, managing feature rollouts — PostHog is the better tool. Nothing else in the self-hosted space combines session replays, feature flags, A/B testing, and event analytics in a single stack.

If you need both web and product analytics, run both. Matomo tracks your marketing site. PostHog tracks your application. They do not compete — they complement.

Most self-hosters reading this comparison want a Google Analytics replacement. That means Matomo.

FAQ

Is PostHog’s hobby deployment suitable for production?

PostHog explicitly labels their self-hosted deployment as “hobby” — it is designed for evaluation and low-volume use (~100K events/month). For production workloads, PostHog recommends their cloud product. Matomo’s self-hosted version is production-grade with no usage disclaimers — it powers high-traffic websites with millions of pageviews per month.

Can I add session replays to Matomo without PostHog?

Yes — Matomo has a session recording plugin, but it is a paid premium plugin (~€199/year). PostHog includes session replays for free in the self-hosted version. If session replays are important but you want Matomo for web analytics, you could run both: Matomo for traffic analytics, PostHog for session replays only.

Which tracking script is lighter?

Matomo’s default tracking script is ~22 KB. PostHog’s JavaScript SDK is ~80 KB with session recording enabled. On slow connections, PostHog’s script adds noticeable page load time. If page speed is critical (and it always matters for SEO), Matomo’s smaller script has less impact. Plausible at <1 KB is the lightest option if you want minimal impact.

Can PostHog track traditional web metrics like bounce rate?

PostHog can calculate bounce rate from its event data, but it is not a first-class metric in the dashboard — you need to create a custom insight. Matomo displays bounce rate, average visit duration, and pages per visit prominently on the default dashboard. If traditional web analytics metrics are your primary concern, Matomo presents them more naturally.

Does Matomo support feature flags?

No. Feature flags are outside Matomo’s scope. If you need feature flags alongside analytics, PostHog is the only self-hosted platform that bundles both. Alternatively, use Matomo for analytics and a dedicated feature flag tool like Unleash or Flagsmith.

Which handles more data efficiently?

PostHog’s ClickHouse backend is designed for high-volume event analytics — it excels at analytical queries across billions of events. Matomo’s MariaDB backend works well for web analytics at most scales, but large installations (10M+ pageviews/month) need careful tuning (report archiving, MySQL optimization, Redis caching). For raw query performance on massive datasets, ClickHouse wins. For typical website analytics volumes, MariaDB is more than adequate and simpler to manage.

Related

• How to Self-Host PostHog
• How to Self-Host Matomo
• Best Self-Hosted Analytics
• Plausible vs Matomo
• Self-Hosted Alternatives to Google Analytics
• How to Self-Host Plausible
• How to Self-Host Umami
• Docker Compose Basics