Posthog to MongoDB: How to Move Your Data

Moving PostHog into MongoDB is worth doing for one specific purpose: serving a single user's activity to an application quickly. A support tool showing what a customer did before they complained needs a fast lookup by identifier, which is what MongoDB does well.

This guide covers the managed path with Airbyte. Two things shape the build: PostHog's rate limits are shared across your whole organisation, and MongoDB is a poor place to aggregate, which makes this pairing right for lookups and wrong for analysis.

Posthog to MongoDB at a glance:

Why move data from Posthog to MongoDB?

One situation genuinely suits this, and it is worth being clear about the other.

The good case is serving activity to an application. A support agent opening a customer record wants that person's recent events immediately, and a document store retrieving by key is an excellent way to provide it. Calling PostHog's API for every such lookup is not, both because of latency and because those calls compete with everything else your organisation does against the same limits.

The poor case is analysis, and it is the more common reason people reach for this. Product analytics is aggregation by nature, counting events, measuring funnels and comparing cohorts, and MongoDB is noticeably weak at all of it compared with anything columnar. If that is your intention, Posthog to ClickHouse will serve you far better, and choosing it now saves rebuilding later.

What do you need before you start?

Four things, and the first is a question rather than a credential:

Confirmation that you want lookups rather than analysis. If anybody downstream intends to count, group or build funnels, this is the wrong destination and the problem will not become obvious until queries are slow and awkward to write.

A PostHog API key and your instance details. Bear in mind the limits that key works against are organisation-wide rather than yours alone. The PostHog source documentation covers the configuration and the streams available.

A sense of your event volume. PostHog recommends batch exports rather than the API where volumes are high, and knowing roughly what a day produces tells you whether this connector is a sensible route at all.

A MongoDB cluster and an index plan. The field your application looks up by needs an index, and the pipeline creates none. Without it every lookup scans the collection, which removes the only advantage this destination was chosen for.

If your cluster 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 MongoDB pipeline in Airbyte?

Step 1: Check this is a lookup problem

Ask what queries the destination will actually serve. Retrieving one person's events by identifier is a lookup and suits MongoDB. Counting events per week, comparing cohorts or measuring a funnel is aggregation and does not. This costs one conversation and prevents the common outcome where a pipeline is built correctly, works as designed, and disappoints everybody who wanted to analyse something with it.

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, base URL and start date. Select only the streams you need, because most of them full refresh on every sync and each one you add is a recurring cost against limits your whole organisation shares.

Step 3: Configure the MongoDB destination

Click Destinations, then New Destination, and select MongoDB, following adding a destination. Supply the connection string, database and credentials. Documents arrive with metadata fields the destination adds, so application code should request the fields it wants by name rather than assuming a document contains exactly what PostHog sent.

Step 4: Create the connection, then build the indexes

Click Connections, then New connection, select your streams and a sync mode. Events supports incremental and the rest do not, so the schedule you choose applies a full refresh to those every time. Once the first sync finishes, index the field your application queries by before letting anything near the collection.

Use the events time step to control how many days each request covers during the backfill, which is the lever that keeps a large history from consuming your organisation's entire allowance.

Why do your syncs affect other teams?

Because PostHog applies rate limits across the organisation rather than per key. Creating a new key does not create new capacity, so your pipeline, somebody's dashboard integration and a script a colleague wrote last year are all drawing from the same allowance, and a heavy backfill is felt by all of them.

That makes stream selection a courtesy as well as a configuration. Only events syncs incrementally; the other streams full refresh on every run, which means each one you keep is re-read in full at whatever interval you chose. The persons stream deserves particular attention, since it grows with your user base and being re-read entirely every sync is not a cost that stays small.

The events time step is your main control during a backfill, setting how many days each request covers. Smaller steps mean more requests against a shared limit; larger ones mean heavier individual requests. And if your event volume is genuinely high, PostHog's own advice is to use batch exports rather than the API, which is worth heeding before you spend a week tuning a pipeline that was never the recommended route.

What can MongoDB actually do with this data?

Retrieve documents by key, quickly, which is genuinely useful and narrower than most people expect when they set this up. Given an index on the person identifier, fetching everything a particular user did is fast and scales comfortably, and that is a real capability worth building a pipeline for.

What it does poorly is everything product analytics normally means. Counting events by type across a month, comparing this week's activation rate against last quarter's, or building a funnel all require scanning and grouping large numbers of documents, which is the workload MongoDB handles least well. Those queries will work, slowly, and be unpleasant to write.

So treat this as an application datastore rather than an analytics one, and if both are needed, run two pipelines rather than compromising. Index deliberately from the access pattern you designed around, remember that nothing in the pipeline creates indexes for you, and keep the collection to the events your application genuinely surfaces rather than everything PostHog holds, since a smaller collection serves lookups faster and costs less to maintain.

Frequently asked questions

Will a separate API key give me more capacity?

No. PostHog's rate limits apply across the organisation, so additional keys divide the same allowance rather than adding to it.

Which streams sync incrementally?

Events only. The others full refresh on every sync, so select them sparingly and watch persons in particular as your user base grows.

Can I run funnel analysis against this data?

Technically yes and you will not enjoy it. MongoDB is weak at aggregation, so funnels, cohorts and counts belong in a column store instead.

My backfill is taking forever.

Adjust the events time step, which sets how many days each request covers. If volumes are high, PostHog recommends batch exports over the API entirely.

Can I do this without writing code?

The pipeline, yes. Creating indexes is yours to do, and without them the lookups this destination was chosen for are collection scans.

Get your Posthog data into MongoDB

Confirm first that you want lookups rather than analysis, because this pairing serves the first well and the second badly. Select streams sparingly, since only events is incremental and the limits you consume belong to your whole organisation. Use the events time step to keep a backfill civil, take PostHog's advice about batch exports if volumes are high, and build your indexes the moment the first sync completes.

Airbyte's connector catalog includes 600+ pre-built connectors, so product data can reach the applications that need it. For the same source into another application backend, see Posthog to Convex, and for another event-shaped source into the same destination, Firebase Realtime Database to MongoDB.

Start syncing now →