The data warehouse in PostHog Web

The PostHog web app is home base for the data warehouse. It's where you link sources, watch them sync, write SQL across everything at once, save the useful queries as views, and turn the results into insights the rest of your team can read.

Open the SQL editor to see the schema browser: your PostHog tables, every synced source table, and your saved views, all queryable together. It's also the only surface where you can change a view's SQL, because a view's definition lives in PostHog rather than in your repository.

Before you start

1. Set up the Data Warehouse – link a source so there are tables to query.
2. Open the web app – no install needed, just sign in to PostHog.

What you can do here

• Link sources – connect Stripe, Postgres, Salesforce, HubSpot, and dozens more, pick which tables to sync, and re-run or reset a table when a sync goes wrong.
• Query with SQL – run HogQL against your events, persons, and sessions alongside every synced source table.
• Join data across sources – connect a source table to your PostHog data so product and business data answer the same question.
• Create views – save a query as a view and reference it from other queries.
• Materialize views – refresh a view on a schedule instead of recomputing it on every read.
• Visualize with insights – turn any query into a SQL insight and put it on a dashboard.
• Fix a query with PostHog AI – when a query in the SQL editor errors, PostHog AI can repair it with your real schema in context. It's an interaction mode inside the SQL editor, not a separate surface, and it's the only place PostHog AI touches the warehouse.

Self-driving reports

PostHog raises warehouse problems on its own – a materialized view that stopped refreshing, or a source whose sync keeps failing – and they land as reports in the Self-driving inbox. To get these reports, set up Self-driving.

• Pick up warehouse signals – PostHog watches the import side for the moments a source stops keeping its promise: a connection in error, a table schema that failed or is stuck mid-sync, silent staleness behind a green status, a dead webhook channel, and materialized views that fail to refresh. Each one becomes a signal carrying the source or view name and the underlying error, so a stale dashboard lands in your queue instead of going unnoticed. When imports are healthy, it looks for optimization candidates instead – expensive query shapes worth materializing, and materialized views nobody reads.
• Diagnose the failure – start a discussion with an agent about the report to work out whether a column was renamed, an upstream source is itself broken, or the query is now too heavy to finish.

A view's definition is stored in PostHog, not in your repository, so a fix to a view's SQL doesn't come as a pull request. Apply the corrected query to the view here in the web app. The check clears once a materialization succeeds.

Related

• Start with Get started with the data warehouse.
• Run the same queries from your editor over MCP.
• Automate the same work with the API.
• Point a SQL client, a BI tool like Metabase, or your own code at your warehouse.
• Restrict who can query tables and views with warehouse access control.
• Check troubleshooting when a query or sync misbehaves.