PostHog

PostHog combines autocapture with explicit event tracking and writes everything to ClickHouse, where it is queryable through the UI or directly in SQL. One identity spans every product, so you can jump from a funnel drop-off to the session replays behind it, or gate a feature flag on a behavioral cohort, without stitching tools together. Each product is priced and metered separately, all riding the same event stream.

The data model is worth understanding before you instrument. Events are immutable rows in ClickHouse — each carries a distinct_id, a timestamp, properties, and a reference to a person. Persons live in PostgreSQL, and their properties are copied onto each event at ingestion time; you manage them with $set, $set_once, and $unset. Because events can’t be changed once written, there is no row-level editing or selective deletion later, so get event names and property shapes right early.

The identity split matters for both analysis and billing. Anonymous events don’t create person profiles and are billed materially cheaper — PostHog says up to 4x — but they can’t be attributed to a user across sessions or segmented by person properties. Identified events unlock all of that; the docs’ advice is to call identify as early as possible with a genuinely unique ID. Anonymous events captured before a user was identified won’t retroactively attach to the person profile on their own, which is the most common surprise in new implementations.

Pricing has no named plans: every product has a monthly free allowance (1M analytics events, 5K replays, 1M flag requests, 1.5K survey responses, among others), then per-unit rates that decline with volume. Adding a card lifts limits like project count and retention. Budget conversations therefore revolve around event volume and how much of it is identified.

On self-hosting, be clear-eyed: the code is MIT-licensed and a Docker Compose deploy is free, but it is officially unsupported, all paid-plan features are Cloud-only, and PostHog itself suggests it only for roughly hobby scale (their docs cite under ~300K events per month). Treat “open source” here as transparency and an escape hatch, not a supported on-prem product.

Migrating in is well-trodden: managed migrations pull history from Mixpanel, Amplitude, or S3, with guides for Google Analytics, Heap, Plausible, and LaunchDarkly. Historical imports go through the batch API or Python SDK with historical_migration enabled so backfilled events skip standard ingestion billing; every event needs a distinct_id and an ISO 8601 timestamp.

Use it when an engineering-led team wants analytics, replay, flags, and experiments consolidated in one tool with SQL escape hatches and transparent, usage-based pricing. Look past it when you need a supported self-hosted deployment at scale, or a polished, analyst-friendly UI for non-technical stakeholders.