Self-Hosted vs SaaS Analytics: When to Pick Which

“Should I self-host my analytics?” is one of the most asked, least usefully answered questions in the privacy-analytics space. The honest answer depends on roughly six things, none of which are “do you care about privacy” — that’s table stakes either way in 2026. The real decision sits at the intersection of your engineering bandwidth, your data-sovereignty requirements, your traffic shape, and your tolerance for being the person who gets paged at 2am when the analytics database fills its disk.

I’ve run both — Matomo Cloud and self-hosted, Umami self-hosted, Plausible self-hosted, GoatCounter on a $5 VPS — across portfolio sites for the past four years. This article is the framework I actually use to decide, the trade-offs I’ve watched teams stumble into, and the migration paths that work in either direction.

What we’re actually comparing

“Self-hosted” and “SaaS” sound like a binary. They’re not. There are at least four meaningfully different setups, and the choice between them isn’t the cartoon “host your own = control / pay vendor = convenience” trade-off most articles imply.

The four real options:

• Vendor-managed SaaS. The vendor runs the database, the dashboards, the ingest pipeline. You paste a snippet on your site. You pay monthly. (Plausible Cloud, Fathom, Simple Analytics, Pirsch, Matomo Cloud, Umami Cloud.)
• Single-binary self-host. One small process, SQLite or embedded database, no separate services. You run it on a $5 VPS or in a Docker container. (GoatCounter, Plausible, single-binary mode.)
• Multi-service self-host. A web tier, a database tier (Postgres or ClickHouse), sometimes a caching tier, sometimes a worker tier. You run them on your own infrastructure. (Matomo on its full stack, Umami with Postgres, Plausible with ClickHouse for high traffic.)
• Managed-self-host. A third party runs the self-host stack on infrastructure you nominally own. (Hetzner-managed Matomo, Cloudron, Coolify deployments.)

The middle two are where most “should I self-host” debates actually live. Single-binary self-host is closer to SaaS in operational cost than to multi-service. Multi-service is closer to running a database in production than to “running an app”. The conflation costs teams real time.

The six factors that actually decide it

Here’s the framework. Each factor pulls you toward one side of the line. Rate yourself on all six, count the votes.

1. Engineering bandwidth

This is the factor most teams underestimate. Self-hosting an analytics tool isn’t a setup cost — it’s an ongoing cost. Database backups, version upgrades, SSL renewal, log rotation, capacity monitoring, incident response when the disk fills up because you forgot ClickHouse partitions need pruning. None of that work disappears just because the tool is “lightweight”.

The honest budget for a properly-run self-hosted multi-service analytics stack is around 4-6 hours of engineering time per month, plus an unexpected outage every 6-9 months that consumes a working day. For a single-binary self-host, it’s closer to 1-2 hours per month. For managed-self-host, you’re paying someone else for that time.

Self-host if: You have a DevOps team that already manages similar services. You enjoy this kind of work and have spare hours. Your team has run Postgres or ClickHouse in production and knows what to do when it complains.

SaaS if: You’re a one-person team. Your engineers’ time is worth more than the vendor’s monthly fee. You don’t have on-call rotation for non-product systems.

2. Traffic volume

SaaS pricing scales with pageviews. At low traffic — under 50k pageviews per month — almost every SaaS option is cheap or free. At medium traffic — 100k-1M pageviews — you’re typically paying $20-80/month per site. At high traffic — 10M+ pageviews — the SaaS bill can hit four figures monthly.

Self-hosting flips this curve. The marginal cost of an extra million pageviews on a self-hosted Plausible install is roughly the cost of the disk space those events consume, which is pennies. The fixed cost — VPS, engineering time — stays the same.

So the breakeven is somewhere between 1M and 5M pageviews per month, depending on which SaaS you’re comparing against and what you value engineering time at. Below that, SaaS wins on cost. Above, self-host wins.

Self-host if: You’re consistently above 5M pageviews per month, or you expect to be within 12 months. Your traffic is spiky and you don’t want to be charged on the peak.

SaaS if: You’re under 500k pageviews per month and your traffic curve is predictable.

3. Data-sovereignty requirements

This is where most self-host arguments get made — and most are over-applied. The cases where data residency genuinely demands self-host:

• Healthcare data subject to HIPAA business-associate-agreement constraints.
• Government / public sector with explicit data-residency mandates.
• Defence-adjacent industries with security-clearance requirements.
• Some German Bundesland-level privacy regulations that require physical EU residence and prohibit US-affiliated processors.

The cases where SaaS with EU hosting is fine:

• Standard GDPR compliance for marketing sites.
• Most B2B SaaS, even with privacy-conscious customers.
• Ecommerce, even with EU customer data.
• Any site where the analytics vendor has a Data Processing Agreement and EU servers.

Most teams reach for self-host when they don’t actually need to. Plausible Cloud, Pirsch, Simple Analytics, and Matomo Cloud all offer EU-resident hosting with proper DPAs. Our comparison dashboard shows which vendors host where, and the privacy-friendly analytics guide covers the legal scaffolding for the standard GDPR case.

Self-host if: You’re in one of the four categories above, or your legal team has explicit data-residency requirements that no SaaS vendor can satisfy.

SaaS if: You’re “just” GDPR-compliant without unusual residency mandates. Pick a vendor with EU hosting and a clean DPA.

4. Customisation and extensibility

Self-hosting gives you the database. The database gives you arbitrary SQL queries, custom dashboards built on top of the raw data, ETL into your warehouse, and integrations that the vendor’s API would never allow.

If your analytics needs are “show me the standard reports” — which is what most sites need — none of that matters. If you have an actual data-team using the analytics output for product decisions, custom queries against the raw event store can be transformative.

Caveat: most “we need custom queries” requirements turn into “we need three specific custom dashboards” which most SaaS APIs can serve. The threshold for genuinely needing raw database access is higher than teams think.

Self-host if: You have a data team. You have specific custom dashboards or integrations that the vendor APIs can’t serve. You want to ETL events into Snowflake or BigQuery for cross-product joining.

SaaS if: The vendor’s standard reports cover your needs. The vendor has a Stats API for the few extras you want.

5. Backup and continuity posture

SaaS gives you a vendor-managed backup that you have no control over. Self-host gives you whatever backup discipline you actually maintain — which is often worse than the vendor’s.

The honest assessment: most self-hosted analytics installs I’ve inherited have either no backups, untested backups, or backups that haven’t run in months because someone changed a credential. The vendor’s “we back up to three regions” is, in practice, more reliable than the typical self-host setup.

This flips for organisations with a serious DR programme — backups in a separate-region object store, restore drills every quarter, runbooks for the on-call. If you have that, self-host wins because you control the rotation policy.

Self-host if: You have an established DR process for production systems and treat analytics as one of them. You’ve actually restored a database from cold backup in the past 12 months.

SaaS if: Your backup discipline is “we’ll figure it out if it breaks”. The vendor’s process is better than yours.

6. Vendor-lock-in risk

The SaaS-vendor-disappearing risk is real but usually manageable. Most privacy-analytics vendors offer data export (CSV or API), and most of them have published their schema, so a migration path exists even in the worst case.

The harder risk is pricing change. Vendors raise prices, change tier definitions, eliminate the plan you’re on. The 100k-pageviews-for-$9 plan that worked great in 2024 might be the 50k-for-$15 plan in 2027. You don’t have leverage to negotiate as a small customer.

Self-hosting gives you immunity from both risks. The trade-off is the engineering cost above.

Self-host if: Your analytics is mission-critical for product decisions and you can’t tolerate an unplanned migration. You’ve been burned by a vendor pricing change before.

SaaS if: You’re comfortable doing a vendor migration every 2-3 years if needed. Your data export is well-rehearsed.

The decision tree

Score yourself on each of the six factors. If you have four or more pulling toward self-host, self-host. If you have four or more pulling toward SaaS, pick a SaaS vendor. If it’s a 3-3 split, the answer depends on which factors are bigger for you.

For most small teams I’ve worked with, the score lands 5-1 toward SaaS. The single self-host vote is usually traffic volume, and the right move there is to pick a SaaS that prices on unique visitors rather than pageviews — which most privacy-first vendors do.

For teams I’ve worked with at scale-up companies, the score is more like 3-3, and the deciding vote is engineering bandwidth. If they have a real DevOps capability, self-host wins on customisation and lock-in. If they don’t, SaaS is the safer bet.

For one-person indie sites and small SaaS, SaaS wins almost universally — except when the founder genuinely enjoys running infrastructure, in which case GoatCounter on a $5 VPS or Plausible self-hosted via Docker is fine.

What the migration actually looks like

SaaS to self-host

The migration is one-way friendly: most SaaS vendors export historical data via CSV or API, and the self-hosted version of the same vendor (Plausible Cloud → Plausible self-hosted, Matomo Cloud → Matomo self-hosted) can usually import that history directly. The work is mostly devops setup, not data juggling.

The trap: people set up the self-hosted version, then leave the SaaS install running for “a couple of months” to compare. Now you’re paying for both, and your team has two dashboards to look at. Pick a cutover date, do a 7-day overlap for verification, then decommission the SaaS.

For Matomo specifically, the cloud-to-self-host migration is well-documented and reliable. Our Matomo review covers the engineering work involved.

Self-host to SaaS

This is the harder direction. Self-hosted history is often in a custom schema (especially if you’ve been running for a while and the vendor has migrated schemas), and the SaaS import path may not exist. Practical options:

• Don’t import historical data. Start fresh on SaaS, keep the self-host instance as a read-only archive for the first year, then decommission it.
• Export aggregates only — monthly totals by page, by country, by referrer — and store them as a CSV next to the new install. This is what most teams actually do.
• Run both for a transition period and let the SaaS catch up to “useful comparison ranges” (90-day, 12-month) before fully cutting over.

The cross-vendor comparison

If you’ve decided on SaaS, the question becomes which one. The seven privacy-analytics tools we cover differ on roughly five dimensions: pricing tier, hosting region, feature depth, open-source status, and self-host availability (because some SaaS vendors also offer self-host as a fallback).

The three above are the cleanest options if you want flexibility — start SaaS, migrate to self-host later if your traffic justifies it. Plausible is the most polished SaaS but the most engineering-intensive self-host (ClickHouse setup). Matomo is the most feature-rich but the heaviest. Umami is the lightest self-host but the least feature-rich on the SaaS side.

If you’ve ruled out self-host entirely, the picture changes. Fathom, Simple Analytics, and Pirsch are SaaS-only — they don’t ship a self-host build. They tend to compete on UX polish and specific privacy guarantees rather than flexibility.

Common mistakes I see teams make

Choosing self-host because “it’s cheaper”. The infrastructure cost is cheap. The engineering time is not. If you’re spending 4 hours of senior engineer time per month on analytics maintenance, you’ve likely already exceeded the SaaS bill you were avoiding.

Choosing SaaS without checking the data export. The vendor seemed great. Then two years later you needed to migrate, and the export was CSV-only at daily granularity, with no event-level data, and your team had been making decisions off custom-event reports that don’t survive the export. Always check the export format before committing.

Choosing self-host without an upgrade plan. Self-hosted analytics tools ship security patches every couple of months. If you’re not running them, you’re running an outdated version, which means missing features, missing fixes, and eventually missing the migration window when the vendor changes the database schema. Establish an upgrade cadence (monthly or quarterly) before you ship.

Treating analytics like a “set and forget” install. Both options need ongoing attention. SaaS needs a quarterly review of the vendor (have they raised prices, changed terms, been acquired). Self-host needs the monthly maintenance noted above. Neither is genuinely fire-and-forget.

What I’d actually pick for different situations

Indie blog or one-person SaaS. SaaS, almost always. Plausible if you want a polished UX, Pirsch if you want EU-only hosting, Simple Analytics if you want the lightest possible setup. Self-host only if you genuinely enjoy running infrastructure.

Small business with a marketing site. SaaS. Pick the cheapest vendor that meets your privacy bar — for most, that’s Plausible Cloud or Pirsch.

Mid-size SaaS with engineering capacity. Either, depending on bandwidth. If your team already runs Postgres or ClickHouse in production, self-hosted Plausible or Matomo is fine. If they don’t, Matomo Cloud or Plausible Cloud Business plan.

Enterprise with data-residency mandates. Self-hosted Matomo, almost always. The compliance team will want it; the data team will want the SQL access; the budget can absorb the engineering cost.

Government or healthcare. Self-host. Don’t even consider SaaS unless your legal team has explicitly cleared a specific vendor.

Anyone running 10M+ pageviews per month. Self-host the data tier (ClickHouse + Plausible, or Matomo + MariaDB), but consider managed-self-host providers if you don’t have spare DevOps capacity. The economics tip toward self-host at this scale, but only if the engineering side is solved.

The wider picture

The self-hosted-versus-SaaS debate is symptomatic of a larger choice teams are making about how much infrastructure they want to own. Five years ago, “host your own” was a privacy moral high ground. In 2026, it’s an engineering capacity question, and the privacy moral high ground belongs to whoever has the cleanest data-collection scope, regardless of where the bytes physically live.

For most small teams, that means picking a SaaS vendor with EU hosting, a clean DPA, and a published privacy posture. For larger teams with engineering bandwidth and specific compliance requirements, self-host earns its keep. The mistake is treating the choice as ideological when it’s actually operational.

Pick on the six factors above, ignore the marketing copy of either side, and revisit the decision every couple of years as your traffic, team, and compliance requirements shift.

Frequently asked questions

What’s the cheapest way to self-host privacy analytics?

GoatCounter on a $5 Hetzner VPS, single-binary, SQLite. About 5 minutes of setup. Handles up to a few million pageviews per month before you need to think about scaling.

Can I migrate from Plausible Cloud to self-hosted Plausible without losing data?

Yes — Plausible offers a CSV export of historical data which the self-hosted version can import. The migration is well-documented. Budget a working day for the engineering work plus a 7-day verification overlap.

Is Matomo Cloud just self-hosted Matomo with a vendor on top?

Effectively, yes. The codebase is the same. The Cloud version handles infrastructure, backups, and version upgrades. The self-hosted version is identical functionality, but you do that work. The Cloud pricing is reasonable; the breakeven for switching to self-host is usually around the 1-2M pageviews/month mark.

Does self-hosting analytics actually improve privacy?

Only marginally. The privacy gain comes from the tool’s data-collection scope, not where the database lives. A self-hosted Matomo with full PII collection enabled is no more private than a SaaS Plausible with cookieless tracking. The self-host argument is mostly about data sovereignty, not privacy posture.

What about hybrid setups — Cloudflare Workers as a server-side ingest in front of a SaaS backend?

This is Pattern 7 from our cookie consent UX guide — first-party server-side ingest plus SaaS backend. It splits the difference: you control the user-facing endpoint (no banner needed for first-party requests), the vendor handles the data store. Plausible’s first-party proxy guide is the cleanest reference implementation. Worth considering if you’ve outgrown plain SaaS but don’t want a full self-host.

Should I be worried about my SaaS analytics vendor being acquired?

Some yes, some no. The privacy-first vendors that have built brands around their stance — Plausible, Fathom, Simple Analytics — tend to have founders who explicitly resist acquisition. The ones backed by VCs are more vulnerable. The risk-mitigation is: pick a vendor with a clean export format, run a backup of your historical data quarterly, and have a Plan B on the shelf. Don’t let analytics be the thing that makes you panic-migrate during an acquisition.

How do I know when I’ve outgrown SaaS?

Three signals. First, the SaaS bill exceeds a senior engineer’s monthly cost. Second, you have specific custom-query needs that the vendor’s API can’t serve. Third, your compliance team has flagged data-residency concerns that the vendor’s DPA doesn’t satisfy. If you’re hitting one of these, start planning. If you’re hitting two, migrate.