Umami vs Plausible vs Matomo in 2026: Which Self-Hosted Analytics?

The mistake most founders make picking analytics is treating Google Analytics 4 as a baseline. GA4 is not a baseline. It is a complex enterprise-grade product designed for an advertising company that needs to track users across the open web. For a small SaaS that just wants to know "did this post get traffic, did people sign up, and where did they come from?", GA4 is overkill, slow, and increasingly hostile in regulated jurisdictions. Umami vs Plausible vs Matomo is the honest 2026 comparison for self-hosted alternatives. We run Umami across all five SaaS in the studio. Here is the comparison and why.

What each one is

A short framing.

Umami is a lightweight self-hosted web analytics tool. Single Postgres or MySQL backend. Privacy-first by default. Open source under MIT.

Plausible is a lightweight analytics tool with a similar privacy-first ethos. Self-hostable (via the community edition) or as a managed cloud product. Built on ClickHouse + Postgres.

Matomo is the heavyweight veteran of the category. Started as Piwik in 2007. Self-hostable, open source. Functionally close to Google Analytics with hundreds of features.

These are not the only contenders. Pirsch, Fathom, Simple Analytics, Counter, and others exist. The three above are the ones most teams choose between.

The honest comparison table

Real production criteria, not marketing site features.

Dimension	Umami	Plausible	Matomo
Self-host complexity	Low	Medium	High
RAM footprint	~150 MB	~500 MB	1 to 4 GB
Database	Postgres or MySQL	Postgres + ClickHouse	MySQL or MariaDB
Default features	Pageviews, events, sources, geo	Pageviews, events, goals, sources	Everything (heat maps, session replay, ecommerce, A/B)
Query depth	Basic	Basic	Deep
Privacy compliance	RGPD-friendly	RGPD-friendly	Configurable
Cookie-free	Yes	Yes	Configurable
Real-time updates	Yes	Yes	Yes
Custom event tracking	Yes	Yes	Yes
API for queries	Yes	Yes	Yes
Setup time on a fresh server	15 min	30 min	60 min
Best for	Small SaaS, blogs	Privacy-focused content sites	Enterprise / agencies needing GA-parity

A few elaborations.

RAM matters more than people admit

A self-hosted analytics stack that takes 2 GB of RAM is a real cost on a 4 GB VPS. We learned this the hard way: we ran PostHog Hobby on a 12 GB CT for a single project and still hit memory pressure. The PostHog instance was decommissioned and replaced with Umami. The full migration story is in our PostHog to Umami migration writeup.

Umami fits comfortably in 256 MB of RAM. Plausible needs more because of the ClickHouse layer. Matomo's footprint depends on how many features you enable.

Query depth varies wildly

If you need session replay, heat maps, A/B tests, ecommerce funnels, custom report builder, only Matomo gives you all of that out of the box. Umami and Plausible give you the 80% that most SaaS need (traffic, sources, conversions, basic events).

If you find yourself wishing for a feature in Umami or Plausible, the question is whether you actually need it or whether you are anchored on GA4 patterns. For 80% of SaaS, you do not need it.

Why we run Umami

Honest reporting on the choice.

We run Umami at insights.draftedby.com, a self-hosted instance that handles analytics for the studio site, the lesson-planning monorepo, jdchess, jdteachai, and the marketing pages for Carriva. The container runs on our homelab with a dedicated Postgres instance.

The reasons:

1. RAM footprint is small. Our Umami container uses about 150 MB resident at typical traffic. Postgres adds modest overhead. The whole analytics stack runs on a small CT.
2. The data lives in Postgres. We can query it ourselves with SQL when we need a custom report. Not locked to a vendor's UI.
3. No cookies by default. RGPD-friendly out of the box.
4. Features map cleanly to our needs. Pageviews, events, conversion events, source tracking. We do not need session replay for marketing pages.
5. It does not break. Umami is boring software in the best sense. Set up once, runs.

The honest tradeoffs:

• Limited dashboard customization. Pre-built dashboards. If you want a custom report, you write SQL.
• No advanced features. No funnels in the UI (we build them with SQL queries on the underlying Postgres). No session replay. No A/B testing.
• The pretty dashboards are not as polished as Plausible's. Plausible's UI is more visually refined.

We accepted the tradeoffs because the simplicity wins. The broader self-hosting story for analytics is documented in our self-hosting analytics 2026 writeup.

Why we did not pick Plausible

Plausible is a fine product. We tested it before settling on Umami.

Reasons we did not pick it for our setup:

1. The dual-database story (Postgres + ClickHouse) doubled the operational footprint for marginal value at our scale.
2. The community-edition vs managed-cloud distinction felt unclear from the docs. We wanted the most predictable open-source path.
3. The UI is prettier but our team does not look at the UI often. We mostly query the data directly.

Plausible would be the right choice for a content-heavy site where the dashboard is the primary surface and the team is not engineering-heavy. For us, the data-in-Postgres simplicity of Umami won.

Why we did not pick Matomo

Matomo is the right choice for a different shape of company.

Reasons we did not pick it:

1. The footprint is too heavy for our infrastructure. 1 to 4 GB of RAM for marketing analytics is more than we want to spend on the line item.
2. The feature surface is too wide for our use case. We do not need heat maps. We do not need session replay. We do not need ecommerce funnels for static marketing sites.
3. The setup is longer. A cleanly-configured Matomo install takes a serious afternoon.

For an agency, an enterprise, or a team migrating off GA4 with a feature-parity requirement, Matomo is the right answer. For a small studio that wants a few key numbers visible, it is overkill.

What goes wrong with each

Honest failure modes we have encountered or seen.

Umami

• Custom queries require SQL. If your team has no SQL skills, the upper limit of what you can ask is what the dashboards show.
• The events model is simpler than enterprise tools. Hierarchical events or session-level analysis is doable with SQL but not via the UI.
• The product is a small team. Updates happen at the pace a small team can ship.

Plausible

• The community edition occasionally lags the cloud edition on features. Verify before committing.
• ClickHouse adds operational complexity that is real.
• Plausible's pricing on the cloud side is per-pageview-tier, which can scale awkwardly for content-heavy sites.

Matomo

• The feature breadth is overwhelming. Most teams use 10% of what is there.
• Performance tuning is real at higher traffic. Matomo on default settings struggles past some volume.
• The UI is showing its age in some areas.

What about Google Analytics 4

A note since we mentioned it. GA4 is technically free and very capable. Reasons we are not running it across the studio:

1. RGPD compliance is genuinely complicated for European traffic. The data leaves the EU. Cookie consent is required in most jurisdictions for the right configuration. The legal risk is real.
2. The GA4 UI is hostile to occasional users. The exploration interface assumes daily usage.
3. Data ownership. Your historical analytics live on Google's servers. If you ever want to migrate off, you are stuck.

For a SaaS targeting EU customers, self-hosted analytics is not a privacy purist position; it is a pragmatic compliance position. We covered the broader self-hosting privacy story in our self-hosting analytics 2026 writeup.

The PostHog question

PostHog is the elephant in this room. It is feature-rich, open-source, and self-hostable.

Reasons we moved off PostHog Hobby:

1. RAM footprint at 12 GB for a single project's analytics. Unacceptable for our infrastructure budget.
2. Operational complexity. PostHog has many moving parts (Postgres, ClickHouse, Redis, Kafka). Each one is a thing that can break.
3. Feature surface beyond our needs. Session recording, feature flags, A/B testing, heatmaps. We do not use most of these on marketing pages.

The full migration story is in our PostHog to Umami migration writeup. Short version: PostHog is excellent for product analytics on a SaaS app where you actually use feature flags and session replay. For marketing analytics on a studio site, it is overkill at high operational cost.

Self-hosted analytics should be the smallest tool that answers your real questions. If you cannot list the questions you ask of your analytics, you do not need analytics; you need to figure out your questions.

What questions to ask before picking

A handful of questions to clarify the choice.

1. What questions do I want to answer? Pageviews? Conversions? User behavior on the app? Funnel drop-off?
2. What is my expected traffic volume? Under 1M monthly views? 1 to 10M? More?
3. Do I have engineering capacity to run a heavy stack? Or do I want set-and-forget?
4. What is my privacy/regulatory context? EU traffic? US-only? Healthcare? Financial?
5. Do I need custom dashboards? Or do pre-built views answer my needs?

The combinations:

• Small site, basic questions, EU traffic → Umami.
• Content site, marketing-heavy, polished UI matters → Plausible.
• Enterprise / agency, feature parity with GA4, RAM budget exists → Matomo.
• SaaS app with feature flags and session replay → PostHog or paid tools.

The integration with your stack

Each of the three integrates similarly: a small JavaScript snippet on your pages, plus optional event tracking calls in your code.

For Umami, the integration is one script tag plus a small JS API for custom events:

window.umami?.track('signup_started', { plan: 'pro' });

We integrate Umami across all our pages. The total bundle weight is under 5 KB. No measurable performance impact.

The same pattern applies to Plausible and to Matomo's modern tracker. The differences are in the data model behind the snippet, not in the integration surface.

Backup and continuity

Self-hosted analytics is your responsibility to back up.

For Umami, the data is in Postgres. We back up Postgres on the same schedule as our other databases, with backups stored off-host on a NAS and a copy in a third location. Standard 3-2-1 backup discipline.

For Plausible, you back up both Postgres and ClickHouse. The ClickHouse backup is more involved.

For Matomo, you back up MySQL/MariaDB.

If you do not have a backup discipline, do not self-host analytics. The data is part of your understanding of your business; losing it is a real cost. Use a managed alternative.

How this connects to content marketing

Analytics is the measurement layer for everything else. We covered the specific economics of content marketing for SaaS in our AI content marketing numbers writeup. The numbers in that piece came from Umami queries: which articles drove signups, which posts had high time-on-page, which sources sent qualifying traffic.

Without lightweight, queryable analytics, content marketing is a guessing game. With a self-hosted instance you can SQL-query, content marketing becomes measurable and improvable.

What we would test first

If you are picking analytics for a small SaaS in 2026:

1. Spin up Umami on a small VPS or container. It takes 15 minutes.
2. Add the snippet to your site. Wait a week.
3. See if the dashboard answers your questions. If yes, ship it.
4. If no, list the missing questions. Decide whether SQL queries can answer them or whether you need a heavier tool.
5. Only graduate to Plausible or Matomo with evidence that Umami is the bottleneck.

We have shipped Umami on five products. We have not had to graduate. The tool fits the use case.

TL;DR

Umami for the small-team default in 2026. Plausible for content-heavy sites that value UI polish. Matomo for enterprise feature-parity needs. Skip GA4 if you can. Skip PostHog unless you actually use feature flags and session replay. Umami vs Plausible vs Matomo is mostly about how much complexity you can accept for how much feature depth. Pick the smallest tool that answers your real questions.