PostHog's architecture

Last updated:

|Edit this page

This section covers PostHog's data model, ingestion pipeline, ClickHouse setup and data querying. This page provides an overview of how PostHog is structured.

Broad overview

There are only a few systems to consider.

  • A website and API for users
  • An API for client apps
  • A plugin service for processing events on ingestion
  • A worker service for processing events in response to triggers

Zooming closer

Adding detail reveals the flow between parts of the system.

Zoomed right in

No communication is needed into or out of this namespace other than the ingress controller for the app and collecting data.

Questions?

Was this page useful?

Next article

Data model

PostHog’s data model starts with events , single actions that a user triggered at a specific point in time. These are sent either from one of our SDKs or directly via our API . Events are flexible: they can be captured automatically, via autocapture , or you can emit your own custom events , attaching additional metadata via properties . You might create an event to represent purchasing an upgrade, with custom properties like price or renewal_period . Meanwhile, users of your product…

Read next article