PostHog for SaaS Analytics in 2026: Self-Hosted vs Cloud
Somewhere in the first month of every SaaS project I've shipped, someone asks the same question: how do we actually know if anyone is using this. PostHog for SaaS analytics gets pitched as the tool that answers that question and three others at once, since it bundles product analytics, session replay, feature flags, and now AI observability under a single SDK. The bundling is real. The decision that actually matters, self-hosted or cloud, gets skipped past far too often, and it's the one that decides whether you spend your first quarter building product or babysitting a database server nobody on your team signed up to run.
Is PostHog Cloud Enough, or Have You Already Outgrown It?
For nearly every SaaS under a few million monthly events, PostHog Cloud is the correct default and self-hosting is a distraction. PostHog's own team says as much: Cloud is "far and away the best experience for the vast majority" of users, a strange thing to read on a self-hosting doc page until you notice it's the same team maintaining both options and choosing not to oversell the harder one. The free tier is generous enough to test the claim yourself: 1 million analytics events, 1 million feature flag requests, and 5,000 session replay recordings, every month, at zero cost, per PostHog's 2026 pricing page. That covers a genuinely large slice of pre-revenue and early-revenue SaaS traffic without a credit card anywhere near the equation.
You've probably run the math already, if you're the kind of founder who runs the math before committing to a stack decision. A B2B tool with two hundred active weekly users firing a dozen tracked events each lands nowhere near a million a month. A dozen events. Nowhere close. The ceiling that actually matters here isn't event volume at all. It's data residency: does a customer contract, a regulator, or an internal security policy require analytics data to never leave infrastructure you control. If the answer is no, stop reading this section and go build your product instead.
When Self-Hosting Actually Pays Off
Self-hosting PostHog earns its complexity only when a regulator or a contract forbids analytics data from leaving your own infrastructure, full stop. PostHog's 2026 open-source disclaimer is unusually candid about the ceiling: a self-hosted, single-machine deployment is "unlikely to scale past a couple 100ks events without significant effort in scaling." Read that twice. The company selling you the managed version is telling you, in its own documentation, that the free version tops out around a couple hundred thousand events before you're doing real infrastructure work just to keep it standing.
This is roughly where Callidus lives. The B2B SaaS I built for UK aesthetic clinics runs on Firestore, not Postgres, and clinic patient data sits under enough regulatory weight that shipping session recordings to a third-party, US-headquartered SaaS was never going to clear a compliance review, regardless of what any vendor's certification page claims. For B2B SaaS selling into regulated verticals, that's the actual trigger for self-hosting: not cost, not event volume, but a customer's legal team drawing a hard line around where data physically lives.
A self-hosted instance also lives in one region by default, so users on the far side of the world from your Docker deployment feel every millisecond of that round trip the same way any centralized service does before someone bothers pushing work out to edge computing-style regional nodes. PostHog Cloud already runs its ingestion behind multiple regions. Matching that yourself is another line item on the self-hosting bill most comparison posts leave off entirely.
If none of that applies to you, self-hosting just to dodge the monthly bill is usually a bad trade. You're swapping a subscription for an ops job, and ops jobs have a way of not staying small.
PostHog for SaaS Analytics: Cloud vs Self-Hosted, Side by Side
| | PostHog Cloud | Self-Hosted (Open Source) | |---|---|---| | Setup time | Minutes — hosted SDK snippet | Hours to days, full Docker Compose stack | | Support | Official, SLA-backed on paid plans | None — "officially unsupported" by PostHog itself | | Data residency | US or EU region choice, PostHog-managed | Fully under your own control | | Realistic ceiling | Scales to hundreds of millions of events | "a couple 100ks events" before real ops work begins | | Cost model | Usage-based after the free tier | Infra spend plus your own engineering time | | Feature parity | Full product surface, always current | Delayed — patches ship to Cloud first |
The parity row is the one people miss when they're comparing feature lists on paper. Every security patch and every new capability, including the AI observability layer PostHog has been building out, reaches Cloud customers first and reaches the open-source Docker image on its own separate schedule. If you're self-hosting specifically to stay independent of a vendor's roadmap, you're actually running behind it.
The Deploy Day Nobody Warns You About
In a 2026 dev.to post, Mohammad Ismail Mirza documented twelve hours of self-hosted PostHog debugging that the official deploy docs simply don't cover: a health check pointing at a Kubernetes-internal URL that doesn't exist outside PostHog's own cluster, a Redis lock that survives container restarts and hangs the whole scheduler, and Nginx quietly caching a dead Docker IP after every redeploy. None of it is exotic. All of it is an afternoon lost. Wednesday morning, actually, in his case.
How Do You Design Events That Still Make Sense at 10 Million Rows?
Name every event category:object_action in snake_case with present-tense verbs pulled from a fixed list, or your analytics rot within two quarters. PostHog's own product-analytics docs push exactly this convention, and the reasoning holds up once real volume hits: signup:button_click, never SignupButtonClicked or clicked signup. Present tense, not past tense — "submit" and "create," not "submitted" and "created." One shared verb list, visible to the whole team, so nobody quietly invents a seventh synonym for "opened."
- Pick one naming scheme before the first event ships, not after the fiftieth one has already gone out under three different conventions.
- Write the allowed verb list somewhere the whole team can see it, and enforce it the way you'd enforce a lint rule.
- Never generate an event name dynamically from a variable. Fixed strings only, or grep stops working the day you need it most.
- Review every new event added in a pull request the way you'd review a database migration, because functionally, that's what it is.
On BookBed, every step of the booking flow fires one event, booking:step_advance, carrying a step_number property instead of a fresh event name per step. Five steps, one event name, one property doing the counting. That's the entire trick, and it's the reason the funnel still reads cleanly two years and several redesigns later.
Feature Flags and Session Replay: Why the Combo Beats Either Alone
Feature flags tell you what shipped. Session replay tells you what happened once it did. Used separately, most teams either guess at rollout risk or drown in hours of replay footage with no good way to filter it down. Used together, flag a canary release, then filter session replay to just the cohort behind that flag, and you watch the exact slice of users hitting your new billing flow instead of scrolling through everyone's Tuesday.
This is the one place I'd argue the bundling genuinely beats stitching together point solutions yourself, more than the AI observability angle PostHog has been pushing since folding LLM tracing into the same product surface. Flags plus replay solve a problem you already have this quarter. AI-trace correlation solves a problem you might have later, or might not.
What's the PII Rule That Lets You Ship Session Replay Without Legal Chasing You?
Mask every input and text element by default, then unmask only the specific fields your team has explicitly decided are safe to record. PostHog's own privacy documentation recommends exactly this posture: start from mask-everything, add narrow exceptions, never the reverse. Pair it with sanitize_properties on captured URLs, since query strings carry password-reset tokens and API keys more often than teams expect, and a session recording that captures a live auth token is a security incident wearing a UX-research costume.
You've shipped a "quick" replay integration before locking down the masking config, haven't you? Most teams have, once, usually right before an audit.
Actually — the masking-by-default behavior is already PostHog's own default for text inputs. What you still own is everything outside plain text fields: the URL bar, any custom autocapture properties, and backend events you send manually from your own server code. Those are the leaks the vendor default can't close for you.
If you're still deciding what else belongs in the stack around this one decision, the rest of your SaaS MVP stack probably matters more than whether you pick Cloud or self-hosted analytics. Get auth, billing, and data isolation settled first. The analytics call is reversible. Most of the others aren't.
Open your PostHog project today and check one number: how many of your currently tracked events would survive a rename if you enforced the category:object_action convention retroactively. If the honest answer is "most of them wouldn't," that's the fix worth making before you touch anything about self-hosting.