PostHog to BigQuery: How to Sync Your Data
Sync PostHog into BigQuery with Airbyte. Organisation-wide rate limits, tuning events_time_step for backfills, and when to use batch exports instead.
Syncing PostHog to BigQuery gets product analytics out of a tool built for product questions and into a warehouse where it can be joined against revenue, support tickets, and everything else. Airbyte does it without code. But there is a decision to make first, and PostHog's own documentation makes it for you if you read closely.
PostHog recommends batch exports for large or regular exports of events. That is not a swipe at Airbyte, it is a statement about rate limits. The PostHog source reads the REST API, and the analytics endpoints are capped at 240 requests per minute and 1,200 per hour. Critically, those limits apply to your whole organisation, not to the API key. A colleague running a script against the persons API can throttle your sync, and your sync can throttle them. If you are moving hundreds of millions of events, use batch exports. If you are moving a few million plus everything else PostHog knows, this connector is the right tool.
The one knob that matters
The events_time_step setting controls how many days of events the connector requests per slice. It is optional and easy to overlook, and it is the difference between a first sync that completes and one that dies partway through.
Large step sizes mean fewer, heavier requests. Small step sizes mean many light ones. Neither is universally right. If your backfill covers two years of a high-traffic product, a small step keeps individual requests within what the API will return and lets the sync checkpoint more often, so a failure at hour six does not cost you hours one through five. If you are syncing a low-volume instance, a larger step finishes faster. Start small for the backfill, raise it for steady state.
Six full-refresh streams, and why that is usually fine
Only events is incremental. Projects, annotations, cohorts, feature flags, insights, and persons are re-read in full on every sync, which sounds wasteful and mostly is not, because these are configuration objects rather than event volumes. Cohort definitions and feature flags number in the hundreds for most instances, not the millions.
Persons is the exception to watch. On a consumer product with a large identified user base it can be genuinely large, and it is re-read every time. If your sync is slow and you have already tuned events_time_step, look at persons next. Splitting it into its own connection with a slower schedule is a legitimate fix.
Setup on both sides
You need a personal API key from PostHog and a start date. If you self-host, change base_url from the default to your instance. On the BigQuery side, supply a project, a dataset, a service account with dataset-level write access, and a Cloud Storage bucket for staging on anything but small syncs.
Airbyte lands each stream as its own table with the raw payload preserved. PostHog event properties are nested, so plan on a downstream model that extracts the properties you actually query rather than making analysts navigate the raw structure every time.
Frequently asked questions
Why is only the events stream incremental?
The connector was built that way. 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.
Does the PostHog rate limit apply per API key?
No. PostHog applies the limit across your entire organisation. Other tools and scripts using different personal keys share the same budget as your Airbyte sync.
Can I sync from a self-hosted PostHog instance?
Yes. Set base_url to your instance URL. Self-hosted instances are not subject to PostHog Cloud's rate limits, though your own infrastructure becomes the constraint instead.
Should I use batch exports instead of Airbyte?
For high-volume event replication, PostHog says yes and they are right. Many teams run both: batch exports for the event firehose, Airbyte for cohorts, flags, insights, and persons.
Get your PostHog data into BigQuery
PostHog to BigQuery is a good pipeline with one real constraint, and the constraint is an organisation-wide rate limit rather than anything in the connector. Tune events_time_step before you tune anything else, watch persons on large instances, and be honest about whether your event volume belongs in a REST-based sync at all.
For another behavioural source landing in the same warehouse, see AppsFlyer to BigQuery. If BigQuery is a staging layer rather than the final home, BigQuery to Snowflake covers the next hop.
Integrate with 600+ apps using Airbyte
Move data from 600+ sources into warehouses, lakes, and beyond. Set up pipelines in minutes with pre-built connectors and the Connector Builder.