PostHog Deep Dive — Own Your Product Analytics Without Selling Your Data

1. What PostHog Actually Is

PostHog is an open-core product analytics platform that tries to be the single place where a software team understands how its product is used. Most analytics tools stop at "how many people visited and where did they click." PostHog goes further by bundling several historically separate products into one stack: product analytics (funnels, retention, trends, paths, SQL), session replay (recordings of real user sessions), feature flags, A/B experiments, surveys, error tracking, and a newer layer of LLM observability. The pitch is that these features share one event pipeline, so you do not need to glue five vendors together with brittle integrations. The company behind it, PostHog Inc., is VC-backed and offers a managed cloud. But the core of the product is released under the MIT license and is fully self-hostable. That is the part this article cares about: the open-source, run-it-on-your-own-metal edition, and what it really costs and requires. Why does this matter for the self-hosting and data-sovereignty crowd? Because product analytics is some of the most intimate behavioral data a company collects. Every click, every feature used, every path a user takes through your app is a high-fidelity behavioral record. Sending that stream to a third-party SaaS means that vendor can see, retain, and potentially monetize or subpoena that data. Self-hosting PostHog is one of the few realistic ways to get Amplitude-grade product analytics while keeping the raw event stream inside your own infrastructure and jurisdiction.

2. The Data Sovereignty Thesis

The core reason to self-host product analytics is not "I hate SaaS." It is that analytics data is uniquely sensitive and uniquely sticky. Once behavioral events leave your network, you have lost control of where they are copied, how long they are retained, and who can subpoena them. A self-hosted PostHog deployment means the event warehouse — the ClickHouse database that stores every tracked action — lives on disks you control, in a region you choose, under a backup policy you define. This is a different class of control than "privacy-friendly analytics." Tools like Plausible and Umami are excellent for cookieless, lightweight website analytics, but they are not built for deep product analytics: funnels across features, cohort retention, user-level paths, experiment results. PostHog occupies the Amplitude / Mixpanel tier of capability while giving you the self-hosting escape hatch those vendors do not offer. The nuance, which we will return to, is that self-hosting does not automatically make you compliant or private. You still decide what you capture, how long you keep person profiles, and whether you point session replay at screens that contain personal data. Ownership of the infrastructure is necessary but not sufficient. The governance is still yours to get right.

3. Architecture Overview

Understanding the bill starts with understanding the architecture, because PostHog is not a single binary. At its heart it is a distributed system:

• Frontend: a Next.js application that serves the dashboard and app UI.
• Backend (API + worker): a Django (Python) monolith handling ingestion, query serving, flags, experiments, and background jobs.
• ClickHouse: the analytical column store. This is where the bulk of your event data lives, and it is the dominant consumer of disk and RAM.
• Kafka: the ingestion buffer. Events are written to Kafka first, then consumed into ClickHouse. This decouples ingestion spikes from query performance.
• Redis: caching and queueing for background work.
• PostgreSQL: the system of record for metadata — organizations, projects, dashings, feature flag definitions, persons' identity mappings, and configuration.

This is a serious stack. The "hobby" deployment collapses some of these (Kafka can be run in a lighter mode, Redis and Postgres can share a node), but the production-recommended topology is a genuine distributed system. That is the first honesty check: PostHog is not something you drop on a $5 VPS and forget. It is closer to running a small data platform.

4. What You Actually Get in the Open-Source Edition

The MIT-licensed community edition includes the headline features that make PostHog worth discussing:

• Product analytics: trends, funnels, retention, user paths, stickiness, and a SQL editor that queries the underlying ClickHouse directly.
• Session replay: client-side recordings you can scrub like a video, with DOM-based capture rather than pixel recording.
• Feature flags: boolean and multivariate flags, with targeting by property, percentage rollout, and payloads.
• Experiments: A/B/n tests wired to the same event data, so results are computed in-place rather than stitched from a second tool.
• Surveys: in-product surveys triggered by behavior.
• Error tracking: capture and group frontend and backend exceptions.
• LLM observability: tracing and evaluation for AI features, a newer addition reflecting where product teams are spending effort in 2026.

What is gated behind the paid Enterprise Edition matters just as much. Granular role-based access control, project-level permissions, SAML/SSO enforcement, audit logs, and advanced security controls are enterprise add-ons. For a solo operator or a small team this is usually fine; for a regulated enterprise it is the single biggest "read the license" caveat.

5. Installation: The Hobby Docker Compose Path

The documented quick start is a single Docker Compose file that bundles the services. For a low-volume deployment — a side project, an internal tool, a startup validating the idea — this is genuinely the right place to start. You clone the repo, set a handful of environment variables (mostly secrets and a domain), and docker compose up. The stack comes up on one host. The realistic ceiling for the single-node Compose deployment is low-volume production or development. PostHog's own guidance suggests self-hosting is sensible up to roughly 300,000 events per month. Past that, the operational burden of tuning ClickHouse and Kafka yourself begins to outweigh the infrastructure cost savings versus the managed cloud. That number is the single most important planning figure in this entire article, and we will anchor cost math to it. A practical home-lab or small-VPS setup for the hobby path typically needs: 4 vCPU, 8 GB RAM minimum to breathe, and a fast SSD. The first time ClickHouse compacts and the Kafka log grows, under-provisioned RAM is where it falls over. Plan for headroom, not the bare minimum.

6. Installation: The Production Kubernetes Path

Real production deployments use Helm charts on Kubernetes. This is where PostHog stops being a weekend project and becomes platform engineering. You deploy ClickHouse as a StatefulSet with persistent volumes, Kafka as a clustered set of brokers, Redis, Postgres (usually an external managed instance), and the PostHog web/worker pods behind an ingress. The Kubernetes path is warranted when you have throughput, high availability requirements, or a team that already runs K8s. It is not warranted for a single product team that just wants analytics. The operational tax — cluster upgrades, ClickHouse shard rebalancing, Kafka retention tuning — is real and ongoing. If you are evaluating PostHog for the first time, start on Compose, measure your event volume, and only graduate to Kubernetes if the numbers force you there.

7. Event Ingestion and the Data Model

PostHog's data model is built around two objects: events and persons (plus optional groups for account-level analytics). An event is a timestamped action with a set of properties. A person is the longitudinal identity that events attach to, built from distinct IDs that get merged as users log in across devices. Ingestion works in two stages. The client or server SDK sends an event to the ingestion endpoint. PostHog writes it to Kafka immediately (acknowledging fast), then asynchronously consumes it into ClickHouse. This is why ingestion stays responsive even under load: the expensive part (columnar insertion) is decoupled. The trade-off is that there is a small lag between "event sent" and "event queryable," usually seconds, occasionally longer during backpressure. A subtlety that bites newcomers: person merging. If you send events before and after authentication with inconsistent distinct IDs, you end up with split or duplicate persons, which corrupts retention and funnel counts. The fix is disciplined identity resolution — set a stable distinct ID server-side at login. This is a data-modeling discipline, not a PostHog bug, but it is the kind of thing that quietly wrecks trust in your numbers if ignored.

8. The Real Self-Hosting Cost — Compute

Let us put hard numbers on a realistic small deployment tracking up to ~300k events/month, the ceiling PostHog recommends for self-hosting. On a single mid-tier VPS (something like a 4 vCPU / 8–16 GB RAM machine with 80–160 GB NVMe), you are looking at roughly $20–40 per month depending on the provider and region. Hetzner, Contabo, and similar European budget hosts sit at the low end; AWS/GCP at the high end for equivalent spec. If you want redundancy (two nodes, or separating ClickHouse onto its own box), double that to $40–80/month. The components that cost money are predictable:

• Compute: the web/worker pods and the ClickHouse process are CPU- and RAM-hungry. Under 8 GB RAM, ClickHouse compaction will stall.
• Kafka: modest but persistent; it wants fast disk for its log segments.
• Postgres: can be a tiny instance; it holds metadata, not events.
• Redis: tiny.

A rule of thumb: budget at least 8 GB RAM for a comfortable single-node deployment, 16 GB if you want headroom, and treat ClickHouse storage as the second cost driver.

9. The Real Self-Hosting Cost — Storage

ClickHouse storage is where the bill grows quietly. Event data is append-heavy and compresses well in columnar format, but at 300k events/month you are still accumulating a permanent behavioral history. Depending on how many properties you attach per event, 300k events/month can mean anywhere from a few GB to tens of GB per year after compression. If you track 5–10 million events/month (above the self-hosting recommendation, but many teams do it anyway), storage becomes the dominant line item: hundreds of GB, then terabytes, with corresponding egress and backup costs. Block storage on a VPS runs roughly $0.04–0.12 per GB-month depending on the provider. At 100 GB that is $4–12/month; at 500 GB, $20–60/month. Add object storage for backups and ClickHouse backups (you do back up, right?) at similar or lower rates. The honest summary: compute is a fixed monthly fee you can forecast; storage is the variable that scales with how much you track and how long you keep it.

10. The Real Self-Hosting Cost — Egress and Hidden Line Items

Three costs people forget:

• Network egress: SDKs send events from your users' browsers and servers to your PostHog host. If that host is in the cloud, inbound is usually free but the round trips, replay ingestion, and any CDN add up. Budget a modest $5–15/month for egress at small scale.
• Backups: a managed Postgres and ClickHouse backup to object storage. Treat this as non-negotiable. $2–10/month.
• Your time: the largest line item nobody invoices. Tuning ClickHouse, upgrading, debugging Kafka lag — at 300k events/month this is a few hours a quarter; above that, it climbs fast.

Total realistic all-in for a well-run small self-hosted PostHog: $30–90/month, versus PostHog Cloud's usage-based pricing or Amplitude's enterprise contracts that routinely run $10k–60k/year. The self-hosted path wins on recurring cash flow and data control; it loses on your engineering attention.

11. Where Your Data Actually Lives

This is the heart of the data-sovereignty promise, so let us be precise. In a self-hosted deployment:

• Event data — the behavioral gold — is written to your ClickHouse on your disk, in your chosen region. No copy leaves to PostHog Inc. unless you explicitly opt into cloud features or telemetry.
• System metadata (orgs, projects, flag configs, person identity maps) lives in your PostgreSQL.
• Session replays are stored on your infrastructure; they are not shipped to a third party for processing unless you configure external upload.
• Ingestion buffers live in your Kafka.

The jurisdiction is yours. If you run the host in Frankfurt, German/EU GDPR territory applies to the data at rest, and a US subpoena against PostHog Inc. does not reach your instance. That is the concrete, legally meaningful difference from a US-hosted SaaS. You are the data controller, not a processor delegate. The caveat: this control is only as good as your operational hygiene. If you point PostHog at a managed Postgres run by a hyperscaler, your "self-hosted" data is still on someone else's infrastructure. True sovereignty means owning the compute, the database, and the backups end to end — or at least understanding exactly which layer you have delegated.

12. ClickHouse and Storage Tuning

ClickHouse is the engine room. A few operational truths:

• Compression: choose codecs wisely. The default works, but tuning merges and TTLs on old partitions can cut storage dramatically.
• TTLs: PostHog supports data retention policies. If you do not need year-old raw events for compliance, set a TTL and let ClickHouse drop partitions. This is the single highest-leverage cost control.
• Replicas: for high availability you run ClickHouse replicas with replicated tables. That doubles storage cost but removes a single point of failure.
• Backups: use ClickHouse's backup tooling to object storage on a schedule, plus point-in-time Postgres backups.

The trap is treating ClickHouse like a black box. It is forgiving at low volume and unforgiving at high volume. The teams that regret self-hosting PostHog are the ones who scaled events 10x without touching ClickHouse tuning.

13. Identity Resolution and Person Merging

We touched on this in ingestion, but it deserves its own section because it is where analytics trust is won or lost. PostHog builds a person by merging distinct IDs. If your SDK sends a random anonymous ID before login and a stable user ID after, PostHog can merge them via an identify or alias call. Get this wrong and you see three phantom users where there is one real human, or one merged blob where there are three. Best practice, in order: assign a stable distinct ID at the earliest reliable moment, call identify on authentication, and avoid sending PII (email, name) as plain event properties unless you have a reason and a retention policy for it. Remember that persons are stored in Postgres and queryable — they are part of your data footprint, and they are exactly the kind of record GDPR subjects can request to be deleted.

14. Session Replay — How It Works and the Privacy Stakes

Session replay is PostHog's most double-edged feature. It records user sessions as DOM snapshots you can replay, which is enormously useful for debugging "why did the user see a blank screen" without begging them for repro steps. But it can also capture everything a user typed, including into form fields, unless you configure masking. For a self-hosted, data-sovereignty-minded deployment, the correct configuration is strict: mask input fields by default, exclude sensitive pages (checkout, auth, health), and set retention short. The feature is stored on your infrastructure, so you are not leaking replays to a third party — but you are also now the custodian of potentially personal recordings, which carries its own obligation. Replay is powerful; treat it like a camera in the room, because functionally it is one.

15. Feature Flags and Experiments

Feature flags in PostHog let you ship code dark, roll out by percentage, target by property, and attach JSON payloads. Experiments build on flags: you define a goal (an event or trend), assign traffic, and PostHog computes significance from the same event stream it already ingests. The elegance is that there is no separate experimentation vendor to reconcile — the flag exposure and the conversion event share one pipeline. For self-hosters, this is a genuine win. Feature flagging and experimentation are two of the most commonly purchased separate SaaS tools, and PostHog collapses both into the analytics you are already running. The limitation is statistical: at low traffic, experiments take a long time to reach significance, and PostHog will tell you as much rather than declaring a winner prematurely. That is a feature, not a bug, but it frustrates teams expecting instant answers.

16. Integrations and the Data Warehouse

PostHog can sync with external sources (Stripe, HubSpot, Postgres, S3, Snowflake, and more) and exposes its own warehouse view of captured data. For a self-hosted deployment, the warehouse is your ClickHouse, queryable via the SQL editor or directly. This is useful for joining product behavior with revenue data you already own. The honest limitation: deep two-way sync with external warehouses often relies on connectors and, in some cases, cloud-assisted paths. If your compliance model forbids any egress, you should scope which integrations you enable and verify that the sync does not phone home. Most ingestion is local; the integrations are where you must read the docs carefully for a strict data-residency posture.

17. Backups and Disaster Recovery

A self-hosted analytics system with no backup is a time bomb, because the data is historically unique — you cannot reconstruct last quarter's funnel from anywhere else. Your backup plan should cover:

• ClickHouse: scheduled backups to object storage; test a restore quarterly.
• PostgreSQL: system metadata; losing this loses projects, flag configs, and person maps even if events survive.
• Kafka: usually rebuildable from events, lower priority, but worth noting.

A sane small-deployment backup bill is $2–10/month for object storage. The cost of not having it is total loss of your behavioral history. This is not a PostHog-specific risk; it is the universal tax of owning your data. Sovereignty cuts both ways: you get control, and you inherit the responsibility.

18. Upgrades and Day-Two Operations

PostHog ships frequent releases (the version line was in the v0.61.x range as of late 2026, with active daily commits). Self-hosting means you own the upgrade cadence. The upgrade path is generally: pull new images, run migrations, verify. ClickHouse schema migrations can be heavy, so do them in a maintenance window. Day-two operations are where the open-core model shows its edge and its tax. The edge: you get every feature fix immediately, no waiting on a vendor. The tax: you are the on-call engineer when ClickHouse disk fills at 2 a.m. or Kafka consumer lag spikes before a launch. PostHog Cloud spares you this; self-hosting does not. Budget engineering attention accordingly, or the "free" software becomes expensive in the only currency that matters — your time.

19. Honest Limitations

This is the section the marketing pages skip. Self-hosting PostHog has real, named limitations: 1. High operational complexity: it is a distributed system (ClickHouse + Kafka + Redis + Postgres + Django + Next.js). Not a single binary. 2. Resource hunger: 8 GB RAM is a floor, not a recommendation. ClickHouse wants more. 3. Open-core gating: granular RBAC, SAML/SSO, audit logs, and project-level permissions are Enterprise Edition add-ons, not in the MIT core. 4. Scaling ceiling: PostHog itself recommends self-hosting only up to ~300k events/month; beyond that, managing the infra becomes a burden that often exceeds cloud cost. 5. Storage growth is permanent: behavioral data accumulates; without TTLs you pay forever. 6. Person-merging discipline required: misconfigured identity resolution quietly corrupts metrics. 7. Session replay privacy risk: if unmasked, it captures PII you then must govern. 8. You are on call: no vendor SLA, no automatic scaling, no managed incident response. 9. Upgrade toil: frequent releases mean ongoing migration work. 10. Smaller community footprint for self-host issues: most discussion assumes Cloud; self-host-specific knowledge is thinner. 11. Kafka can be overkill at tiny scale: the buffer is necessary for throughput but adds weight for a hobby deployment. 12. SQL access is powerful but unforgiving: a bad query can hammer ClickHouse and starve ingestion. None of these are dealbreakers for the right team. They are, however, the difference between "I installed it" and "I operate it reliably for years."

20. Security and Compliance Posture

The MIT core is genuinely open: you can audit the code, pin versions, and run it entirely air-gapped from PostHog Inc. For compliance, self-hosting puts you in the driver's seat on data residency, retention, and deletion. The EU Cloud option exists if you want managed hosting with EU residency, but the self-hosted path gives you the strictest possible control. The gaps are governance features gated to Enterprise (SAML, granular RBAC, audit logs). If your compliance regime requires those, the community edition leaves a hole you must fill with external tooling — reverse proxy auth, network policies, or an external identity broker. Plan for that gap explicitly rather than discovering it during an audit.

21. Performance and Scaling Ceilings

The ~300k events/month self-hosting ceiling is not arbitrary; it tracks where ClickHouse and Kafka tuning stops being "set and forget" and starts being "a job." Above that, you typically need: dedicated ClickHouse nodes, Kafka broker tuning, replica sets, and someone who understands OLAP performance. At 1M+ events/month, a single VPS is no longer viable; you are running a small data platform with a real monthly bill ($200–500+ for the infrastructure alone, before your time). This is the crux of the build-vs-buy decision. Below the ceiling, self-hosting PostHog is cheap and sovereign. Above it, the infrastructure cost approaches or exceeds the managed alternative, and you are paying with engineering hours on top. Know which side of that line you are on before you commit.

22. PostHog vs the Alternatives

Against the open-source, self-hostable analytics field:

• Plausible: cookieless, lightweight, privacy-first website analytics. Far simpler to self-host (a single Docker image). But it is not product analytics — no funnels across features, no session replay, no experiments. Choose Plausible for marketing-site privacy analytics; choose PostHog when you need deep product analytics.
• Umami: also lightweight, self-hosted, privacy-friendly. Great for simple site metrics; not a product-analytics suite.
• Matomo: the closest open-source analog to Google Analytics, strong GDPR features. More focused on web analytics than the unified flag/experiment/replay stack PostHog offers.
• Amplitude / Mixpanel (SaaS): richer managed analytics, but your data lives with them and enterprise pricing is steep.

The differentiator is bundling plus self-hosting. PostHog is the rare option that gives you Amplitude-class depth and a self-hosted, MIT-licensed escape from vendor data custody.

23. Who Should and Shouldn't Self-Host

Self-host if: you have strict data-residency requirements Cloud cannot meet; you already run infrastructure and have spare capacity; your event volume is under ~300k/month; you want full ownership of behavioral data; you are comfortable operating ClickHouse and Kafka. Do NOT self-host if: you are a non-technical team wanting "just analytics"; your volume is high and you have no platform engineer; you need enterprise RBAC/SAML out of the box; your team's time is better spent on the product than on operating a data platform. In those cases PostHog Cloud (or a lighter self-hosted tool like Plausible) is the rational choice. This is not a moral hierarchy. Sovereignty has a price in attention. Pay it knowingly.

24. A Concrete Deployment Walkthrough

A realistic small production-ish spec for a team tracking up to 300k events/month:

• Host: one VPS, 4 vCPU, 16 GB RAM, 160 GB NVMe, ~$30–45/month.
• ClickHouse: on the same host, dedicated 80 GB volume, TTL of 18 months on raw events.
• Postgres: managed small instance or co-located, backed up nightly.
• Kafka + Redis: co-located, fast disk.
• Reverse proxy: Caddy or Traefik terminating TLS, with forward-auth if you want SSO at the proxy layer.
• Backups: ClickHouse + Postgres to object storage, ~$5/month.
• Monitoring: export PostHog and host metrics to your observability stack.

All-in: roughly $35–55/month plus a few hours of quarterly maintenance. That is the number to compare against the per-event or per-seat SaaS bill. For many small teams it is the cheaper and more sovereign option; for high-volume teams it is not.

25. Monitoring Your PostHog

Because PostHog is itself infrastructure, you should monitor it like any other critical service. Export host and container metrics, watch ClickHouse disk usage and merge rates, alert on Kafka consumer lag, and graph ingestion volume. A sudden drop in events usually means a client SDK regression, not a traffic dip — catch it fast. If you run a broader homelab or self-hosted stack, PostHog slots into the same observability you already use. Pair it with a metrics collectors and dashboards, and with a lightweight dashboard tool for the host layer. The point is not to add a new monitoring silo; it is to treat PostHog as one more service your existing tooling already watches.

26. Common Pitfalls

• Under-provisioning RAM: ClickHouse stalls, ingestion backs up, dashboards hang. Start at 8 GB minimum, 16 GB preferred.
• No TTL: storage grows forever; the bill compounds.
• Broken identity resolution: split persons corrupt retention and funnels. Fix distinct IDs early.
• Unmasked replay: you accidentally record PII. Mask inputs and exclude sensitive routes.
• No backups: one disk failure erases irreplaceable history.
• Upgrading in prod without a window: ClickHouse migrations are heavy. Schedule them.
• Expecting SaaS hand-holding: self-hosting means you are the support desk.

Each of these is avoidable with the discipline this article has emphasized: plan capacity, set retention, govern identities and replays, back up, and own the upgrade cadence.

27. Migration and Exit Strategy

A genuine strength of the open-source edition is portability of the raw data. Events live in ClickHouse as plain rows you can query and export with SQL; persons and config live in Postgres. If you ever leave PostHog, you are not held hostage by a proprietary export format — you can pull your event history directly. The hard part of exit is the shared-event-layer coupling: flags, experiments, and replays all depend on the same captured data. Migrating the analytics is easy; reconstructing flag-exposure history and replay context elsewhere is expensive. So the practical advice is: keep your event schema clean and documented, export periodically to cold storage, and accept that the deeper features are stickier than the raw events. Sovereignty of the data does not mean zero switching cost for the workflow.

28. The Bottom Line

PostHog's self-hosted, MIT-licensed edition is one of the few ways to get Amplitude-class product analytics while keeping the behavioral event stream entirely on infrastructure you control, in a jurisdiction you choose, under a retention policy you set. For teams with real data-residency needs — or simply a principled objection to shipping user behavior to a third party — it is a genuinely sovereign option that lighter privacy-analytics tools like Plausible and Umami cannot match on depth. The honest counterweight is operational: PostHog is a distributed system (ClickHouse, Kafka, Redis, Postgres, Django, Next.js), it wants 8–16 GB of RAM, it is officially recommended only up to ~300k events/month for self-hosting, and its strongest governance features (granular RBAC, SAML, audit logs) sit behind the Enterprise Edition. Realistically budget $30–90/month all-in for a small deployment plus your engineering attention, and treat backups and TTLs as non-negotiable. Below the scaling ceiling and with the right operator, self-hosting PostHog is both cheaper and more sovereign than the alternatives. Above it, the math flips. Own the decision knowingly, and PostHog earns its place in a serious self-hosted stack.

29. GDPR, Deletion, and Data Subject Requests

Because you are the data controller when you self-host, the boring compliance chores land on you. The good news is that PostHog gives you the primitives: you can delete a person and their events through the API or UI, and you can export a user's data for a subject-access request. The bad news is that deletion in ClickHouse is not the instant, transactional wipe people imagine — it is a mutation that propagates, and replicas or backups may retain the data until the next compaction or until the backup ages out. If your retention promise to users says "deleted on request," you must account for the lag and for backup copies, and you must document it honestly rather than pretending the record vanished the moment you clicked delete. Practically, build a small runbook: receive the request, identify the distinct ID(s), call the deletion endpoint, verify the person no longer resolves in queries, and note the backup-retention window during which a restore could reintroduce the record. None of this is unique to PostHog — it is the universal cost of owning behavioral data — but self-hosters sometimes assume "it's on my server" means "I'm automatically compliant." It does not. Ownership means you are the one who has to answer the audit, and the audit does not care that the software was free.

30. Final Recommendations and a 30-Day Plan

If you have read this far, you can make the call confidently. Start on the hobby Docker Compose deployment on a machine with at least 8 GB RAM and a fast SSD. Track real traffic for 30 days and watch three numbers: monthly event volume, ClickHouse disk usage, and your own time spent tending the stack. If events stay under ~300k/month, disk grows predictably, and maintenance is a few hours a quarter, keep self-hosting — you are in the sweet spot where PostHog is both cheaper and more sovereign than the alternatives. If events blow past the ceiling, disk surprises you, or you are firefighting weekly, migrate the analytics-heavy load to PostHog Cloud or a lighter self-hosted tool and keep PostHog only for what you truly need on-premise. Set three things on day one so you never regret it: a retention TTL on raw events, nightly backups of ClickHouse and Postgres to object storage, and strict session-replay masking. Do those and the open-source edition will serve you for years. Skip them and the same sovereignty that protects you will eventually bite you. PostHog is not the lightest self-hosted analytics tool, and it is not the simplest, but for teams that need deep product analytics without surrendering their users' behavioral data, it is one of the few options that respects both your ambition and your autonomy. Run it within its limits, respect the operational tax, and it will repay you with insight you fully own.

Related

• Plausible
• Umami
• Grafana
• Supabase
• Appwrite