PostHog supports three practical database architectures. You can sync an existing warehouse into PostHog, use PostHog’s context warehouse as your working analytics hub, or export PostHog data into a warehouse you control. Endpoints sit above those architectures and serve a saved result to a custom application while the underlying data and business logic stay in the chosen architecture.

I’m JJ, founder of Vision Labs. My team has shipped more than 20 PostHog implementations and manages around 30 accounts, so we’ve had to make this decision across very different data stacks.

Choose based on where cross-source logic should live, who needs the data, how fresh it must be, and who will maintain each flow. Headcount is a rough proxy. The arrows show movement; your governance model decides which copy is authoritative.

Architecture	Primary analytical layer	Best when	Main tradeoff
Existing warehouse into PostHog	BigQuery or another warehouse for core business models; PostHog for synced analysis	Trusted business models already live in the warehouse and PostHog users need selected tables beside product events	PostHog creates another copy and another sync to monitor
Sources directly into PostHog	PostHog for cross-source analysis	A lean team wants fewer tools and most consumers work in PostHog	Less independent control if several teams need governed models outside PostHog
PostHog into the company warehouse	BigQuery, Snowflake, or another company warehouse for downstream models	A data team needs centralized models, governance, and several downstream consumers	More infrastructure, vendor cost, and maintenance

The primary analytical layer is where cross-source models and reporting logic live. Authority can still differ by domain: a source system may remain authoritative even when its data is synced into PostHog or exported to BigQuery.

What do Sources, Destinations, and Endpoints mean in PostHog?

PostHog names Sources and Destinations from its own point of view. Sources bring selected external data in, batch-export Destinations send PostHog data out, and Endpoints expose a saved result over HTTP.

A BigQuery Source syncs selected tables into PostHog, while a BigQuery Destination sends events, persons, or sessions in the other direction. An Endpoint gives an existing insight or HogQL query a stable route that an application can call. Changing the direction creates a different data system; governance determines which copy is authoritative.

PostHog’s data warehouse lets you query synced business data alongside product events. The separate Managed Warehouse beta adds dedicated compute and a PostgreSQL-compatible endpoint, with limited availability. A regular source connection uses PostHog’s context warehouse; a dedicated Managed Warehouse database is a separate product.

Architecture 1: sync an existing warehouse into PostHog

Choose this architecture when BigQuery or another warehouse already holds trusted business models and the product or growth team wants to analyze selected tables inside PostHog.

The flow can look like this:

Meta Ads -> connector or ELT -> BigQuery -> PostHog -> PostHog insights

In the video walkthrough at 1:39, I use Meta Ads and BigQuery as the example. The same model applies to billing, CRM, support, or operational data. PostHog discovers the available tables, then you choose which tables and columns to sync.

PostHog queries the synced copy on its own compute, which lets analysts work with the data inside PostHog. It also creates another copy and pipeline whose permissions, schedule, failures, and row volume need an owner.

For a BigQuery Source, create the credentials through Google Cloud IAM and grant the service account the necessary project and dataset access. PostHog’s current BigQuery source instructions cover the required roles and connection fields.

If revenue, account, subscription, or campaign logic is already trusted in BigQuery, sync only the tables product and growth need. Keep company-wide modeling and governance in the warehouse. Vision Labs covers that layer through BigQuery implementation and management.

Architecture 2: use PostHog as the working analytics hub

Use PostHog as the working analytics hub when most of your questions are answered there and no other team has a concrete warehouse requirement.

The flow is shorter:

Meta Ads, Stripe, CRM, and product database -> PostHog -> HogQL, views, insights, and dashboards

PostHog connects to each supported source and syncs its tables into the context warehouse. Your team can join them to events, persons, and sessions with HogQL, then save the logic as views or insights. Removing an ELT vendor and external warehouse can be practical when one group owns ingestion, analysis, and decisions.

In my Meta Ads example at 4:05, each source configuration uses one account ID. PostHog leaves the naming pattern to the user. When we manage several accounts, we create separate, clearly named sources so an analyst can identify the client or business unit before opening the table.

Freshness depends on the source and its sync behavior. The current Meta Ads source documentation defines full and incremental behavior by table. Use those schedules when setting freshness expectations.

I usually start lean teams here. When finance, operations, product, and marketing need the same governed models in several tools, a company-owned warehouse can justify the extra work. Our PostHog implementation and optimization work covers the identity, source design, metric definitions, and ownership needed to make that transition.

Architecture 3: export PostHog into the company warehouse

Export PostHog into the company warehouse when that warehouse is the governed home for cross-source models used by several teams and applications. PostHog remains the originating platform for its events; the warehouse becomes the modeling and distribution layer for the exported copy.

The flow is:

PostHog events, persons, and sessions -> batch export -> BigQuery -> models, BI, and custom reporting

PostHog’s batch exports currently support BigQuery, Snowflake, Postgres, Redshift, Databricks, S3, and Azure Blob. Events, persons, and sessions are separate models, so you choose what leaves PostHog and configure each export. If you need data from before the export began, request an explicit historical backfill instead of assuming the recurring job will recreate it.

I walk through the destination setup at 5:45 in the video. In production, someone still needs to manage permissions, schedules, destination schemas, failed runs, property changes, warehouse models, and downstream tools. PostHog recommends service-account impersonation for BigQuery destinations when possible instead of a long-lived JSON key.

A company warehouse gives you reusable models and independent control. The same revenue definition can serve finance, a board report, lifecycle marketing, a customer-health model, and an AI application from the governed layer. It can also combine PostHog events with sources that don’t belong in a product analytics tool.

A ten-person company with strict governance and several data consumers may need this architecture, while a much larger product team with simple reporting can stay inside PostHog.

Are PostHog Endpoints a fourth architecture?

No. PostHog Endpoints serve the result of an insight or SQL query to an application. The source data and core business logic can live in PostHog or an external warehouse.

An Endpoint gives a saved query a stable, named HTTP route. It can accept variables, keep versions, show execution logs, use caching, and optionally materialize results. That makes Endpoints useful for an internal tool, customer-facing analytics, or a custom reporting interface that needs PostHog data without recreating the query on every screen.

We use this pattern at Vision Labs. Our report passes a date range to an Endpoint, gets the result, and renders it in an interface built around the decision. The Endpoint handles delivery; the warehouse or synced source still owns the underlying data.

Endpoint freshness comes from the full data path. A direct run can execute when the request arrives. Its result may still reflect the schedule of an upstream source sync, and caching or materialization can add another delay. Trace that path before calling an Endpoint real-time.

PostHog’s Endpoints documentation currently marks the feature as early beta and free during the beta. The Query API comparison explains why a named, versioned Endpoint is easier to operate than sending a complete query payload from every client. We also have a practical PostHog Endpoints walkthrough for the implementation side.

How much does each PostHog data architecture cost?

I compare the whole system: storage, syncs, query compute, connectors, batch exports, modeling, reporting, and the hours required to keep it working.

As of August 24, 2026, PostHog’s pricing page lists the first one million Managed Warehouse rows per month as free. Rows from one million through ten million cost $0.000015 each, so ten million total rows calculate to $135 after the free first million. Historical warehouse syncs are currently listed as unlimited at $0.

Batch exports are billed separately. The first one million exported rows are free, followed by usage tiers. Endpoints are free during early beta, with final pricing still open. Check the live calculator before approving an architecture because rates, free allowances, and beta terms can change.

Calculate the total operating cost. An external stack may add an ELT connector, BigQuery storage and query compute, dbt or another modeling layer, BI licenses, and engineering time. An integrated PostHog setup may add managed rows, sync volume, and less flexibility for downstream uses. Put those items into the same model before comparing totals.

Which PostHog data warehouse architecture should you choose?

For a lean team whose questions are mostly about product or growth, PostHog can be the analytics hub until another consumer creates a concrete warehouse requirement.

If trusted business models already live in a warehouse, sync only the account, billing, campaign, or operational tables PostHog users need beside product events.

Centralized models, governance, several downstream consumers, and independent ownership call for exporting PostHog into the company warehouse. That pipeline needs a budget and a named owner.

Endpoints fit a separate need: giving a custom application access to a PostHog query result while the underlying data ownership remains unchanged.

We use a hybrid ourselves. Some reporting joins data in the warehouse, some screens call PostHog Endpoints, and some PostHog data is exported for other teams. These are different interfaces on one connected system, documented with the direction and owner of every data flow.

Before choosing, make one architecture map. For each data domain, label the authoritative source, primary modeling layer, owner of every sync, and every downstream dashboard, model, campaign, application, or AI workflow. Use that map to compare prices with the correct storage, sync, and query volumes.

At Vision Labs, we map the sources, identities, metric definitions, owners, and decisions before implementation. We then build the PostHog and warehouse layers so dashboards, custom reporting, and AI use the same definitions and history.

If you’d rather have our team design and implement it, see our PostHog implementation and optimization work or schedule a Data Strategy Call.

FAQ

Can PostHog be used as a data warehouse?

Yes. PostHog can be the working analytics warehouse for a team that wants external business tables beside events, persons, and sessions. Sources sync selected data into PostHog, where you can query it with HogQL and build views or insights. The separate Managed Warehouse beta has limited availability and adds dedicated compute with a PostgreSQL-compatible endpoint.

Can PostHog connect to BigQuery?

Yes. PostHog can connect to BigQuery as a data warehouse Source. You grant a Google Cloud service account access, enter the project and dataset details, then select the tables and columns to sync. PostHog stores a synced copy and queries it on its own compute.

Can PostHog export data to BigQuery?

Yes, PostHog can export events, persons, and sessions to BigQuery through separate batch-export models. You configure the destination and schedule, then request a historical backfill if you need data from before the recurring export began. The warehouse can use those exports for governed models, BI, custom reporting, or other downstream applications.

What is the difference between PostHog Sources and Destinations?

PostHog Sources sync selected external data into PostHog, while batch-export Destinations send PostHog data to another system. A BigQuery Source makes warehouse tables available beside PostHog events. A BigQuery Destination moves events, persons, or sessions into the company warehouse. Direction tells you whether PostHog consumes or exports a copy; your governance model determines which system is authoritative and where business logic is maintained.

Are PostHog Endpoints real-time?

Endpoint freshness depends on the full data path. PostHog can execute a saved insight or SQL query when an application makes a request, while source sync schedules, Endpoint caching, and materialized results can delay the data behind it. Trace those layers before promising a real-time experience to users.

Is PostHog or BigQuery cheaper?

The cheaper option depends on the complete operating model. Compare PostHog managed rows, syncs, and exports with BigQuery storage and query compute, then include connectors, modeling tools, BI licenses, and engineering time. A lower storage rate can still produce a more expensive operating model once the whole stack is included.