PostHog to BigQuery: How to Sync Your Data
Move PostHog into BigQuery with Airbyte. Tuning events_time_step, organisation-wide rate limits, and modelling nested event properties.
Moving PostHog into BigQuery lets you join product behaviour to everything PostHog cannot see: revenue, support cost, contract value. PostHog answers what users did extremely well and cannot answer what it was worth, because it does not hold that data.
This guide covers the managed path with Airbyte. The friction is entirely on the way out of PostHog, where rate limits apply across your whole organisation and only one stream syncs incrementally, and one setting decides whether your first sync finishes.
PostHog to BigQuery at a glance:
Why move data from PostHog to BigQuery?
Two situations account for most of these pipelines.
The first is joining. Product usage next to revenue, support load and contract value is where the useful answers are, and no product analytics tool can produce them because it has never seen the commercial side.
The second is modelling beyond the tool: custom attribution, cohort definitions your team argues about, anything needing SQL. If you only need funnels and retention curves, PostHog already answers those and this pipeline earns you little.
What do you need before you start?
Short list, with one item that is a conversation rather than a credential:
A PostHog personal API key and a start date. If you self-host PostHog, change the base URL from the default to your instance. Self-hosted instances are not subject to PostHog Cloud's rate limits, though your own infrastructure becomes the constraint instead. The PostHog source documentation lists every field.
An agreed share of the rate limit. PostHog applies its limits across the organisation rather than per key, so your sync competes with every other tool and script on the account. Find out what else talks to PostHog before choosing a schedule.
An honest estimate of event volume. PostHog recommends batch exports for large or regular exports of events. If you are moving hundreds of millions of events, use those. If you are moving a few million plus cohorts, flags and persons, this connector is the right tool.
A BigQuery service account and dataset. With the BigQuery User and BigQuery Data Editor roles. Set the dataset location to match your revenue and support datasets, since joining them is the point.
If your organisation restricts inbound traffic by IP, add the Airbyte Cloud IP addresses to the allow list before you begin.
How do you build a PostHog to BigQuery pipeline in Airbyte?
Step 1: Decide which streams you actually need
Only events is incremental. Projects, annotations, cohorts, feature flags, insights and persons are re-read in full on every sync. For the configuration objects that is cheap, since they number in the hundreds. Persons is the exception, and on a consumer product with a large identified user base it is genuinely large and re-read every time.
Step 2: Configure the PostHog source
Click Sources in the left navigation, then New Source, and select PostHog, following adding a source. Supply the API key, start date and base URL. Set events_time_step deliberately: it controls how many days of events each request covers, and it is the difference between a first sync that completes and one that dies partway through.
Step 3: Configure the BigQuery destination
Click Destinations, then New Destination, and select BigQuery, following adding a destination. Supply the project, dataset and service account key. Event volumes can be substantial, so consider Cloud Storage staging rather than the default if your first sync is large.
Step 4: Create the connection and schedule it
Click Connections, then New connection, select your streams and a sync mode for each. Use incremental on events. Run the backfill with a short events_time_step even if steady state would tolerate more, because the historical period is where the limits bite.
If the sync is slow after tuning events_time_step, look at persons next. Splitting it into its own connection on a slower schedule is a legitimate fix and usually the right one.
Why does the rate limit affect your whole organisation?
Because PostHog applies its limits at the organisation level rather than per API key. The analytics endpoints are capped at 240 requests per minute and 1,200 per hour, and every tool, script and personal key on the account draws from the same budget.
The practical effect is that a colleague running a script against the persons API can throttle your sync, and your backfill can throttle them. That makes the schedule an organisational decision rather than a technical one, and a large initial backfill something to plan rather than start on a whim.
Many teams end up running both approaches: PostHog batch exports for the event firehose, and this connector for cohorts, feature flags, insights and persons. That is a sensible split rather than a compromise, because the two mechanisms are good at different things.
How should you model event data in BigQuery?
Treat the landed events table as a raw layer rather than something analysts query directly. PostHog event properties are nested and the connector preserves that structure, which BigQuery handles natively but which most people would rather not navigate on every query.
Extract the properties your team queries into typed columns in a view, and keep the raw column so you can reprocess history when the product team adds a property. On a source where new properties appear without warning, that raw layer is what saves you starting from the day you noticed.
Then partition and cluster deliberately. Events accumulate indefinitely and BigQuery bills for bytes scanned, so filtering on the event timestamp should prune partitions rather than scanning years. Establish that convention while there is one query to change rather than a set of dashboards.
Frequently asked questions
Why is only the events stream incremental?
The other streams describe configuration rather than an append-only log, and re-reading them in full is cheap enough that incremental support was never added. Persons is the one to watch on large instances.
Does the PostHog rate limit apply per API key?
No. It is applied across your entire organisation, so other tools and scripts using different personal keys share the same budget as your sync.
My backfill keeps failing partway through. What should I change?
Reduce events_time_step so each request covers fewer days. Smaller slices keep individual requests within what the API returns and let the sync checkpoint more often.
Should I use this connector or PostHog's batch exports?
Batch exports for very high event volumes, which is PostHog's own recommendation. This connector for cohorts, feature flags, insights and persons, and for moderate event volumes.
Can I do this without writing code?
Yes. The setup above is entirely UI-driven. You will want BigQuery views extracting event properties and joining to your revenue data, which is short SQL.
Get your PostHog data into BigQuery
Tune events_time_step before anything else, agree your share of the organisation's rate limit, watch persons on large instances, and establish the partition filtering convention before anyone builds a dashboard on the raw events table.
Airbyte's connector catalog includes 600+ pre-built connectors, so product events can sit beside the revenue and support data that explain them. For the same source in a columnar engine, see PostHog to ClickHouse, and for another product analytics source in the same warehouse, Mixpanel to BigQuery.
Integrate with 700+ apps using Airbyte
Move data from 700+ sources into warehouses, lakes, and beyond. Set up pipelines in minutes with pre-built connectors and the Connector Builder.