Managed warehouse

Contents

The managed warehouse is in beta

Not yet available to everyone – join the waitlist and we'll let you in as soon as it's ready.

The managed warehouse is a full analytical database that PostHog provisions and runs for your organization. Your PostHog data and your connected sources land in it continuously, and you query it like any Postgres database – from psql, from BI tools like Metabase or Grafana, from your own code, or from PostHog itself.

It's the difference between "PostHog can query my data" and "PostHog is my data warehouse": you get a real database endpoint with its own hostname and credentials, holding your product data and business data side by side.

How it works

Under the hood, the managed warehouse is built on DuckDB, with data stored in the open DuckLake lakehouse format on durable object storage. You don't need to know any of that to use it, but it explains the shape of the product:

  1. Provisioning – When you set up the warehouse, PostHog creates a dedicated database for your organization with its own hostname, like my-warehouse.dw.us.postwh.com. Compute is isolated per organization: your queries run on workers spun up for you, not on a shared cluster.
  2. Getting data in – PostHog backfills your historical events and persons, then keeps the warehouse up to date as new data arrives. Sources you've connected (Stripe, Postgres, Salesforce, HubSpot, and so on) sync into the warehouse on the same schedule as their regular imports.
  3. Storage – Data lives as columnar files in S3-compatible object storage with a transactional catalog on top. Storage and compute scale independently, and your data survives any individual machine.
  4. Querying – The warehouse speaks the PostgreSQL wire protocol over TLS, so any Postgres client, driver, or BI tool connects without special adapters. DuckDB's analytical SQL (things like SUMMARIZE and QUALIFY) works too.

Architecture

A closer look at the pieces PostHog manages for you:

  • A Postgres-compatible front end. Connections terminate at a control plane that handles TLS, authenticates your connections, and translates PostgreSQL syntax to DuckDB syntax where the two differ. That's why any Postgres tool works unmodified.
  • Dedicated DuckDB workers. Queries run on DuckDB workers reserved for your organization, spun up on demand and retired when idle. There's no shared query queue, so a heavy query from another customer never competes with yours.
  • Open storage. Tables are columnar Parquet files in object storage, tracked by DuckLake's transactional catalog. Workers come and go; your data doesn't, and it lives in an open format rather than a proprietary store.

How this fits into PostHog

The managed warehouse doesn't replace ClickHouse or any other part of PostHog. Insights, product analytics, and every other PostHog feature keep running on PostHog's existing query engine, unchanged, and your events keep flowing in exactly as before.

The warehouse is an addition: a dedicated database that receives the same data, where you can run isolated workloads with the benefits of DuckDB and DuckLake built in and managed for you. Point BI dashboards, notebooks, and scheduled jobs at it, build your own tables in it, and none of it competes with the queries powering your PostHog project.

What's in your warehouse

Each project in your organization gets its own schema, chosen during setup. Within a project you'll find:

DataWhere it lives
EventsAn events table named after your project's schema, e.g. events_prod
PersonsA persons table, e.g. persons_prod
Source importsA schema per project for imported sources, e.g. posthog_data_imports_prod, with one table per synced source table
Modeled dataA schema holding the outputs of your data models
Your own tablesAnything you create yourself with CREATE TABLE or CREATE VIEW

The exact layout is still settling during the beta, so the reliable way to see what you have is to ask the warehouse itself – \dn and \dt in psql, or DESCRIBE on any table.

Where to go next

Community questions

Was this page useful?