Why We Ditched PostHog for Umami (and When We Would Switch Back)

We ran self-hosted PostHog Hobby on our homelab for nine months. It was eating 12 GB of RAM for a single project. The Hobby tier caps at one project per instance, so to run analytics across our four products we would have needed four instances and roughly 48 GB of RAM. The Scale license to lift that cap starts at thousands of euros per year. We tried Umami. It runs on around 250 MB of RAM. We migrated. This is the honest PostHog vs Umami self-hosted comparison after running both in production.

What we needed from analytics

The use case matters. We are not a heavy product-analytics shop. For most of our products we want:

• Page views with a filter by URL.
• Session counts.
• Top referrers.
• Event tracking for a small number of named events (signup, paid, contacted support, generated).
• A friendly dashboard a non-engineer can read.

We do not need (for most products):

• Funnels with 8 steps.
• Cohort retention with custom predicates.
• Session replay.
• Feature flags tied to analytics.
• A/B test infrastructure.

That distinction is the entire reason this post exists. PostHog is a phenomenal tool for the second list. Umami is a phenomenal tool for the first list. They are not the same product.

Where PostHog Hobby fell apart for us

We ran PostHog on CT 108 in our homelab. The architecture is genuinely sophisticated: ClickHouse, Kafka-like ingestion, Postgres for metadata, a Python web app, a Node frontend. Every component is doing real work.

The problem is that this architecture is sized for a real product analytics workload, not for a small studio's marketing-and-conversion tracking. We had a few thousand pageviews per day across all products. The system was idling at 7 GB of RAM and spiking to 12 GB. We even bumped the container's memory allocation. It still drifted upward.

When the cost of running the analytics is bigger than the cost of running the product, the analytics is the wrong fit.

The killing blow was the Hobby project cap. Running multiple products on one Hobby instance is not officially supported and we tried to make it work with workspace tricks. It always felt like swimming uphill. The honest options were:

1. Run four PostHog Hobby instances, one per product, eating roughly 48 GB of RAM total. Untenable on our hardware footprint.
2. Buy the Scale license, get all features, multi-project, and proper support. The starting cost was more than we wanted to spend on analytics for a small studio.
3. Move to PostHog Cloud free tier, capped at 1M events per month. Workable for a single product but still per-instance limits, and we wanted self-hosted for most of the studio.
4. Pick a lighter tool. That is the road we took.

Why Umami won the replacement bake-off

We evaluated three alternatives: Umami, Plausible, and Matomo.

Plausible self-hosted is great. It has fewer features than Umami in some areas, and the licensing is GPL with terms we wanted to read more carefully before standardizing on it. We did not have a good reason to pick it over Umami for our use case.

Matomo is the most mature option, and on paper it is the best feature set. The catch is that Matomo's most useful features (heatmaps, session recording) are paid plugins. Heatmaps and session recording together run around 290 EUR per year. We have written elsewhere about the OSS plugin trap and how it shapes our self-hosting analytics decisions in 2026. For our use case, the plugin model was a non-starter.

Umami runs on Postgres (or MySQL), is roughly 250 MB of RAM at our usage, and has a clean dashboard that a non-engineer can read in 30 seconds. The MIT license is unambiguous. We picked it.

The migration we ran

The migration was pleasantly anticlimactic.

1. We provisioned a Coolify-managed Umami instance on the homelab. Coolify deploys Umami in roughly 4 minutes from scratch.
2. We picked a memorable subdomain. We use insights.draftedby.com, deliberately not analytics.draftedby.com. Ad blockers eat anything matching *analytics*. Pick a domain that does not look like analytics if you want clean numbers.
3. We added the Umami tracking script to all four products and to draftedby.com itself. Roughly one line per Next.js app.
4. We set up named events for the 8 most important conversions across products. Umami's event API is straightforward.
5. We left PostHog running for two weeks in parallel to make sure Umami was capturing what we expected. It was. We turned PostHog off.

The whole migration took maybe a Saturday afternoon plus follow-up cleanup over two weeks. The savings are 11.75 GB of RAM and zero ongoing software cost.

What we lost (and how much it actually mattered)

To be fair, Umami is not PostHog. We lost some things.

Funnels

PostHog's funnel UI is excellent. Umami has more limited funnel support. For most products, we replaced the PostHog funnel with simpler "raw event count" tracking and a manual calculation. It is a downgrade. It has not stopped us from making any decision.

Cohort retention

PostHog has rich retention analytics. Umami does not natively. For most of our products, we are too small for retention math to drive decisions yet. When we are bigger, we will revisit.

Session replay

We did not use PostHog's session replay much, so losing it cost us nothing. For products where session replay matters (typically free-tier or marketplace products with complex UX) we use Microsoft Clarity, which is genuinely free for heatmaps and session recording. No ad-blocker problems and no paid plugin tier.

Feature flags

We never used PostHog feature flags meaningfully. For now, environment-based feature flags inside our Next.js apps cover what we need. If we grow into needing real flag infrastructure, we will pick a dedicated tool.

The pattern across these losses: most of what PostHog gave us we did not actually use. The 5% that we did use, we replaced with simpler tools or accepted as a downgrade.

The exception: Carriva stays on PostHog Cloud

There is one product where we did not migrate to Umami: Carriva.

Carriva is the most analytically rich product in the studio. The advisor workflow has multi-step funnels (audit started, audit completed, finding shared with client, client converted), the RAG assistant has retention metrics that matter (do advisors come back?), and the free B2C detector has a different funnel from the paid product.

We use PostHog Cloud free tier for Carriva. The 1M events per month cap is generous for our current scale. The cost is zero. When we outgrow the free tier we will look at the paid tiers, but the math will be very different from running self-hosted because we are paying for the analytics depth, not the infrastructure.

The principle: pick the right analytics for each product. Not every product needs the same tool. We discussed the broader analytics philosophy in our case for self-hosting analytics in 2026.

When we would switch back

We are not religious about Umami. Three things would push us back to PostHog (or to Scale licensing):

1. A product crosses real product-analytics scale. When daily active users hit a threshold where funnel decisions and retention sophistication actually drive product roadmap, the cost of richer analytics justifies itself.
2. We start running A/B tests at scale. PostHog's experimentation tooling is solid. Building it ourselves on Umami would be a misallocation.
3. A team of more than one person. Multiple stakeholders looking at the same data benefit from PostHog's collaboration features. For one engineer, it is overkill.

The decision tree is roughly: if you are a small studio with marketing-driven analytics needs, Umami. If you are a real product team with product-led growth metrics, PostHog (probably Cloud, possibly Scale). If you need session recording, Microsoft Clarity (free) plus your main analytics. The choice is not "self-hosted vs hosted". It is "what do I actually need analytics to do?"

The operational notes

For the engineers in the audience, three things to know:

• Umami's tracker is small and fast. It is non-blocking. It does not slow down page loads measurably.
• The dashboard is fine on mobile. We check it on phones during travel.
• The data export is straightforward CSV. We have not had to query the underlying Postgres directly, but if we did, the schema is readable.

We discussed our broader homelab in our piece on the solo dev DevOps Proxmox and Coolify setup. Umami fit into that homelab as one more Coolify-deployed service alongside everything else.

A note on cost-of-ownership math

When you compare self-hosted tools, do not just compare the software cost (zero on both sides). Compare:

• Memory footprint.
• Operational complexity (does it require ClickHouse, Kafka, Redis?).
• Backup and restore time.
• Upgrade pain when the major version bumps.
• The cognitive load of context-switching back into the system every six months.

By those metrics, the PostHog vs Umami self-hosted comparison is not even close for our use case. PostHog is a serious distributed system. Umami is a small, well-built web app. We are a small studio. Match the tool to the team.

The "domain naming" trick we did not see coming

A small detail that mattered more than expected: the subdomain you put your analytics tracker on dramatically affects how much traffic you actually count.

Most ad blockers maintain rules that filter requests to anything matching *analytics* or *tracking* in the hostname. If you serve your tracker from analytics.yourdomain.com, you lose somewhere between 10 and 25% of traffic that would otherwise be counted. We use insights.draftedby.com. We could have used metrics.* or pulse.* or another less-obvious subdomain. The principle is to pick a domain that does not look like analytics on the wire.

This trick is not about deception. The data is still pseudonymous, the privacy posture is still defensible, the GDPR documentation is still in place. The trick is just about not advertising "I am an analytics endpoint" in the URL itself, because some ad-blocker rules use the URL pattern as a heuristic.

The combined effect of self-hosting plus a non-obvious subdomain on our undercount problem was substantial. Our current numbers match server-log estimates within a few percent. That is good enough to make decisions on.

What is next

For the rest of 2026 we will run Umami across most of the studio and PostHog Cloud for Carriva. If a fifth product enters the family, it will start on Umami unless its analytics needs justify otherwise.

The general lesson: PostHog vs Umami self-hosted is not a one-size answer. It is a question of fit. We over-engineered our analytics in 2024 and paid for it in RAM. We right-sized in 2026 and got back our hardware budget. The savings funded better hardware for the products that actually generate revenue. That is the trade you want to make. It just takes the courage to admit you bought the wrong tool first.