Self-hosted product analytics: what you actually run

Most comparisons of self-hosted analytics compare features. Before features, I wanted to know what I’d be on the hook for at two in the morning: how many services, which databases, who answers when it breaks. So I read each project’s install docs and compose files. I checked all of this in November 2026, from the sources listed at the end. I read these files and didn’t install the other four tools, so nothing here is a benchmark of them.

The table

	PostHog	Plausible CE	Umami	Matomo On-Premise	Trailic
Mainly	Product analytics, plus replay, flags, surveys and more	Web analytics	Web analytics with behaviour reports	Web analytics	Page views, events, funnels, retention for Next.js sites
How it deploys	`bin/deploy-hobby` on an Ubuntu VM, Docker Compose	Docker Compose	Docker Compose, an image, or from source	PHP app on your web server	Next.js app on Vercel, or anywhere Node runs
Services	48 entries in `docker-compose.hobby.yml`, some of them one-shot jobs	3 containers	2 containers	Web server, PHP, database, cron	1 app, 1 database, a buffer, 2 scheduled calls
Data stores	Postgres, ClickHouse, Redis, Valkey, Redpanda as Kafka, ZooKeeper, SeaweedFS, Elasticsearch, Temporal, etcd	Postgres 16, ClickHouse 24.12	Postgres 12.14 or later	MySQL or MariaDB	Postgres, no extension
Stated minimum	4 vCPU, 16 GB RAM, more than 30 GB	2 GB RAM recommended, a CPU with SSE 4.2 or NEON	None I could find	2 CPU, 2 GB RAM, 50 GB SSD up to 100,000 page views a month	None. See the load test below
Licence	MIT, except `ee/`, under its own licence	AGPL-3.0	MIT	GPL-3.0, paid plugins under the InnoCraft EULA	AGPL-3.0
Funnels	Yes	Not in CE	Yes	Paid plugin	Yes
Retention	Yes	Couldn’t confirm for CE	Yes	Paid plugin (Cohorts)	Identified people only
Who helps you	“Officially unsupported”, no customer support	Community only	I found no statement	I found no statement for free self-hosters	Nobody yet, open an issue
Real traffic	Yes	Yes	Yes	Yes	None yet

What each one asks of you

PostHog

The most capable of the five, by a distance. The self-hosted version is, in its own words, the same product as PostHog Cloud, so you get session replay, feature flags and surveys, none of which Trailic has. The price is the stack. The hobby compose file lists 48 entries, and the docs’ example is a 16 GB machine. PostHog is upfront about this: self-hosted deployments are “officially unsupported”, it doesn’t do tagged releases for them, and its decision chart asks whether you expect more than 300,000 events before steering you towards Cloud. Treat self-hosted PostHog as a way to try it or to keep a small project in-house.

Plausible Community Edition

Three containers: the app, Postgres, and ClickHouse for events. Small and clear. ClickHouse is the part to watch, since it’s why the README asks for 2 GB of RAM and a CPU with SSE 4.2 or NEON. CE is a long-term release published twice a year. Plausible keeps marketing funnels, user journeys, ecommerce revenue goals, SSO and the sites API for its paid cloud, and it says why: they support the project’s long-term sustainability. If you want pages and referrers and don’t mind that line, it’s a tidy choice.

Umami

The smallest stack I read: one app and Postgres. The docs ask for Node 20.19 or later and Postgres 12.14 or later. MIT, and it has grown well past page counts: its docs now cover funnels, retention, journeys, goals, replays and heatmaps, and it ships an MCP server you turn on with MCP_ENABLED=1. One detail to act on: a fresh install from source creates a login admin with the password umami. Change it first.

Matomo On-Premise

No containers required: PHP, a web server (Apache, Nginx, IIS or LiteSpeed) and MySQL or MariaDB. The requirements page lists PHP 8 with MySQL 5.5 or later for Matomo 5, and PHP 8.1 with MySQL 8.0 or MariaDB 10.6 for Matomo 6. You also need a cron job for report archiving once you pass “a few hundreds visits per day”, hourly by default. It publishes the most detailed sizing of the five, up to more than 100 million page views a month on five servers. Funnels, Cohorts and Heatmap & Session Recording are paid plugins with a 30-day trial. Cookies are on unless you add disableCookies, and then returning-visitor reports become inaccurate.

Trailic

One Next.js 16 app and one Postgres. On Vercel, nothing else is needed for the buffer, since Vercel Queues is on every plan, in beta. But the hourly flush needs a Pro plan, because Vercel’s Hobby plan refuses crons that run more than once a day. Elsewhere you set TRAILIC_BUFFER=file on a disk that lasts, call /api/cron/flush hourly and /api/cron/retention daily, and put it behind a proxy that sets the visitor’s address, because the hash reads it. You also pick one way to sign in: a company’s OpenID Connect provider, Google, or passwords with a Resend key. How to run it has the whole list.

The weak spot is everything operational. There’s no upgrade path between versions yet, the data model may change, and the Vercel Queues buffer has only run against a stand-in for that service. Any of the other four is a safer place today for data you can’t lose.

Sizing it

Published minimums tell you little about your own traffic, so here’s a calculation you can redo. For Trailic I only have one measurement, and it’s synthetic: pnpm load-test loads 5 million generated events over 120 days on 30 sites, into Postgres 17 limited to one CPU and 4 GB.

Raw events took 1.64 GB, about 340 bytes an event, and rollups 139 MB.
A site sending 1 million events a month, kept 90 days by default, holds about 3 million raw rows.
3,000,000 × 340 bytes comes to about 1 GB, and raw storage stops growing there, because old days are deleted. Rollups stay, and they’re small.

In that test, a three-step funnel over 90 days on the biggest site took 130 ms with one CPU and 700 ms with a quarter of one. Journeys from its top page took 3.5 s and 20 s, and they’re the one query that grows with a page’s traffic. Real traffic will behave differently, and I’ll publish it when there is some.

For comparison, Matomo’s page puts up to 1 million page views a month at 4 CPU, 8 GB and a 250 GB SSD. Those numbers answer different questions, a planning guide on one side and a synthetic test on the other, so don’t read them as a race.

The licence, in practice

If you only run it for yourself, all five let you. They differ when you change the code and offer it to others. Under AGPL-3.0 (Plausible CE, Trailic), offering a modified version over a network means publishing your changes under the same licence. MIT (Umami, most of PostHog) asks for none of that. GPL-3.0 (Matomo) applies when you distribute the software. Matomo’s paid plugins and PostHog’s ee/ folder sit outside those terms. More on Trailic’s choice on the open source page.

How I’d choose

Your situation	What I’d look at first
One small server, you want pages and referrers	Umami or Plausible CE
PHP hosting already there, Google Analytics style reports	Matomo
You need replay, flags and experiments, and can give it 16 GB and no vendor support	PostHog
All your sites are Next.js on Vercel, you want funnels and retention in your own Postgres, and you’re willing to test something unproven	Trailic, next to something else

Hosting it yourself doesn’t settle the cookie banner question: you become the one who has to answer it. The glossary entry on self-hosted analytics has the short definition.

Where Trailic stands

Trailic is a first version. It works end to end on a test instance with real browsers, a real assistant and five million synthetic events, but it hasn’t collected real traffic yet. Its Vercel Queues buffer has only run against a stand-in for that service, its data model may change, and there’s no upgrade path between versions. There’s no hosted version, and the library isn’t on npm yet: it lives in the repo at packages/trailic. Session replay, automatic click capture, heatmaps, feature flags, A/B tests, surveys and account health aren’t built. Don’t make it your only analytics yet. The repo is here, and corrections to this table are welcome in the issues.