Why people self-host
Three reasons, all legitimate: the data never leaves infrastructure you control, there is no per-pageview pricing to worry about, and you can query the raw database however you like. For organisations with a policy requirement about data residency, self-hosting can be the only acceptable answer.
The mistake is treating "free software" as "free".
The infrastructure bill
A small analytics instance needs a server and a database. On a modest site that is a small monthly VPS cost. Traffic changes the shape quickly, because analytics writes on every page view — it is a write-heavy workload, and the database is the part that will hurt first.
Add backups, which you need and which cost storage, and monitoring, so you find out the instance died before you notice three weeks of missing data.
The time bill, which is the real one
- Initial setup: a few hours, more if you want it properly secured and behind a reverse proxy with TLS.
- Updates: a monthly-ish task. Analytics platforms ship security fixes and you are the one who applies them.
- Database maintenance: raw event tables grow. At some point you will archive, aggregate or prune, and that is a project rather than a checkbox.
- Incidents: the day the disk fills or a migration fails, the analytics outage is yours to fix, on your evening.
Two hours a month is a fair estimate for a well-run small instance. Price your own time honestly and compare with a subscription before deciding.
The performance question
A hosted analytics service runs on a network built to accept a tracking request from anywhere in the world in a few milliseconds. Your single server in one region does not. If the tracking endpoint is slow for distant visitors, you are adding latency to their page for the sake of your metrics.
This is fixable with a CDN in front, which is more configuration and more cost.
The responsibility
This is the part that gets skipped. Once you host the data, you are the data controller for it in the fullest sense: raw analytics data, which may include IP addresses, sits on your server, in your backups, exposed to whatever your security posture actually is rather than the one you intend.
That means: securing the instance, patching it, encrypting the backups, limiting who can query it, being able to honour access and deletion requests, and being the one who reports a breach if the server is compromised. A vendor with a security team does this as their job.
When self-hosting is the right call
- A policy or contractual requirement that data stays on your infrastructure
- You already run servers and have the operational muscle
- You need raw SQL access for analysis a dashboard cannot express
- Traffic volume is large enough that per-pageview pricing genuinely dominates
When it is not
- You chose it to save a modest monthly fee
- Nobody on the team owns servers as part of their actual job
- The site is small enough that a free tier or a cheap subscription covers it
- You would not notice for a week if the instance stopped collecting data
The honest test is the last one. If nobody would notice, nobody is going to maintain it either.