[Go to site: main page, start]

Data warehouse

Contents

The data warehouse brings your business data into PostHog and puts it next to your product data. Sync Stripe, Postgres, Salesforce, HubSpot, and dozens of other sources, then query them alongside your events, persons, and sessions in one SQL query – no ETL pipeline to build and no second analytics tool to keep in sync.

Once the data is in, you shape it with views and materialized views, chart it in insights, and reach it from your editor over MCP. When a model breaks, it becomes a signal for Self-driving instead of a dashboard that quietly goes stale.

Get started

Where you can use it

Most warehouse work happens in the web app – connecting sources, writing SQL, and building views. The other surfaces bring that same data to wherever you already work.

PostHog Web

Connect sources, write SQL, build views, and chart the results in insights.

Query your data →

PostHog MCP

Run SQL, manage views, and configure sources from Claude Code, Cursor, or any MCP client.

Run queries →

PostHog Desktop Beta

Review the Self-driving work raised by failing models and broken syncs.

Review reports →

API

Manage sources, tables, views, and joins from your own scripts and tooling.

Use the API →

Where its data comes from

Your warehouse is built from data you sync in and data you model on top of it.

Managed sources

Stripe, Postgres, Salesforce, HubSpot, and dozens more, synced on a schedule you set.

Link a source →

PostHog data

Your events, persons, sessions, groups, and query log are queryable by default.

Query PostHog tables →

Files and object storage

Upload CSV, JSON, or Parquet, or read straight from S3, GCS, R2, or Azure Blob.

Upload a file →

Views and materialized views

Saved queries that join sources together and refresh on a schedule.

Model your data →

How the data warehouse works with Self-driving

Your models are monitored, not just stored. When a materialized view stops refreshing, the failure becomes a signal for Self-driving rather than a dashboard that silently serves stale numbers.

Sources and modelsSynced sources, views, and materialized views
Health checksFailed materializations and broken syncs are detected
SignalsEach failure carries the view name and the error
One reportGrouped with the upstream data it depends on
You fix and re-runNothing changes without a human

Because a view's SQL lives in PostHog rather than your codebase, the fix usually happens in the web app – but you can diagnose it from PostHog Desktop or MCP first. See the Self-driving docs for the full picture.

Community questions

Was this page useful?