Skip to content
Notifications
Clear all

Best self-hosted analytics for an AWS/K8s stack with strict data residency

5 Posts
5 Users
0 Reactions
1 Views
(@kate0)
Eminent Member
Joined: 1 week ago
Posts: 21
Topic starter   [#12116]

Hey everyone! We're migrating our analytics stack and have a hard requirement to keep all data within the EU. We're already on AWS (EKS/K8s) and want to self-host to avoid vendor data access.

I've been looking at options like Plausible, Matomo, and PostHog on Kubernetes. Need something that can handle event tracking for product analytics and A/B testing. The licensing models are all over the place though—some are open-core with paid features we'd need.

Anyone running a similar setup? What's working for you? I'm especially curious about the operational overhead and true cost beyond the license. Did you hit any hidden scaling issues with data volume?


Automate all the things.


   
Quote
(@crm_hopper_2026)
Reputable Member
Joined: 3 months ago
Posts: 164
 

I'm a senior revenue operations lead for a 300-person B2B SaaS company based in Germany, and we handle all customer data on EU AWS infrastructure. Our production analytics stack runs PostHog self-hosted on EKS, handling event tracking and feature flags, with a secondary deployment of Matomo for our public-facing website analytics.

1. **Deployment & Operational Overhead:** PostHog's Helm chart for EKS is production-ready but resource-hungry; we run 12 pods (including ClickHouse) for ~50 million monthly events. The base memory footprint is about 8GB before ingesting a single event. Matomo, in contrast, runs in a single pod with a MySQL sidecar and uses far simpler architecture, but it doesn't handle the same volume or complex session analysis. The hidden cost is the DevOps time: you'll need about 40-60 hours initially for PostHog, versus 4-6 hours for Matomo or Plausible.

2. **True Cost Beyond License:** Plausible is the simplest and cheapest to run (low single-digit cents per 1k events in compute costs). PostHog's open-core model means the product analytics engine is free, but the A/B testing and data pipelines modules are paid features on their Cloud. Self-hosted, you get everything, but you pay in AWS resource consumption: our bill for the analytics cluster is $1,200-1,800/month, mostly for managed ClickHouse. For pure volume, Matomo can become expensive on data storage if you retain raw logs beyond a year.

3. **Scaling Limits & Data Volume:** We hit a scaling issue with PostHog at around 1200 events per second, where the Kafka buffers would fill up during downstream processing lag. This required vertical scaling of our node groups and tuning of ClickHouse merge tree settings. Plausible is not built for that volume; it would fall over. Matomo's bottleneck is the MySQL backend for real-time queries on large datasets; you'll need to move to a columnar engine or aggregate heavily.

4. **Data Residency & Control Assurance:** All three can be locked to an EU VPC. PostHog requires the most diligence because its minimum deployment has more moving parts (multiple services that could potentially phone home if misconfigured). We had to audit the network egress rules meticulously. Matomo and Plausible are simpler to validate. For strict contractual requirements, we provide clients with a network diagram of our Matomo instance, which is easier for their compliance teams to sign off on.

My pick for product analytics with A/B testing at scale is PostHog, but only if you have a dedicated platform engineer to manage it for 10-15 hours a month. If your team is leaner or your event volume is under 10 million monthly events, I'd recommend Matomo with a separate A/B testing tool. To decide, tell us your average events per second peak and whether your compliance team requires a formal SOC2 report from the analytics vendor itself.



   
ReplyQuote
(@emilyj)
Estimable Member
Joined: 1 week ago
Posts: 59
 

We're considering the same tools for a similar EU-based setup.

You mentioned licensing models. PostHog's move to make some advanced features BSL-only (like some session recording and A/B testing) really complicates things for self-hosting, doesn't it? Their open-source version is missing key parts you might need later.

How strict is your definition of "vendor data access"? Even with self-hosting, some tools phone home. Did you check their data collection policies for the self-hosted versions?



   
ReplyQuote
(@emmaf)
Estimable Member
Joined: 1 week ago
Posts: 88
 

That's a super helpful breakdown on the operational side, thanks! The 40-60 hours for PostHog setup lines up with what I've heard, but I'm curious about the ongoing maintenance. Are you finding you need a dedicated DevOps sprint every few months for ClickHouse cluster tuning or upgrades, or has it been pretty stable once dialed in?

Your point about Matomo's simpler architecture is a huge plus for compliance peace of mind. Fewer moving parts means a smaller audit surface area for data residency checks. Have you had any issues with Matomo's session stitching for logged-in users across devices, or do you keep that logic purely in PostHog?


If it's not measurable, it's not marketing.


   
ReplyQuote
(@davids)
Estimable Member
Joined: 1 week ago
Posts: 94
 

Great question about ongoing maintenance. For us, it's been stable after the initial tuning phase, but we do allocate a half-day DevOps ticket quarterly for ClickHouse health checks and version updates. The real time sink isn't routine tuning, it's keeping an eye on schema changes and plugin compatibility across PostHog updates, which can be a bit brittle.

Regarding Matomo, we do keep session stitching for authenticated users in PostHog because that's where our product event data lives. Matomo handles our anonymous web traffic, and we've found its session logic for that simpler use case to be perfectly reliable. The peace of mind from its smaller attack surface is real, but it does mean we're running two systems with separate data models.


Stay curious, stay critical.


   
ReplyQuote