Amplitude to BigQuery: How to Move Your Data

Moving Amplitude into BigQuery lets you join product behaviour to everything the business knows about the people doing it. Amplitude answers questions about events beautifully and knows nothing about contract value, support tickets or the cost of serving an account, so the interesting analysis has to happen somewhere else.

This guide covers the managed path with Airbyte. Two things shape the build: the export API refuses to hand over more than a fixed amount at once, and where your data lives matters at both ends in a way that cannot be corrected afterwards.

Amplitude to BigQuery at a glance:

Why move data from Amplitude to BigQuery?

Two situations account for most of these pipelines.

The first is joining behaviour to commercial outcomes. Knowing that a feature is used twice a week is mildly interesting; knowing that accounts using it twice a week renew at a noticeably higher rate is a business case. That join needs revenue and account data Amplitude has never seen, and BigQuery is usually where it already lives.

The second is keeping event history beyond what a product analytics tool is convenient for, and querying it with SQL rather than through a chart builder. The pairing is less suitable if what you want is a raw event lake to reprocess repeatedly, since that is a lakehouse job rather than a warehouse one; Amplitude to Databricks suits that shape better.

What do you need before you start?

Four things, and two of them are decisions you cannot revisit cheaply:

API credentials for each project. Credentials are scoped to an Amplitude project, so an organisation running separate projects for web and mobile needs a source for each. The Amplitude source documentation covers generating them.

Your data region, confirmed rather than assumed. An Amplitude project on EU residency must be read through the residency server, and pointing at the standard endpoint will not quietly work. Ask rather than guess, particularly if the project predates whoever is building this.

A BigQuery dataset created in the right location. Location is set at creation and cannot be changed, and BigQuery will not join datasets across locations. If your revenue data sits in one region, this dataset belongs there too, and if residency rules apply to the events, both facts have to agree.

A sense of your daily event volume. The export API caps each export at four gigabytes, so knowing roughly how much a day produces tells you whether the default time range will work or needs shortening before the first sync.

If your network restricts traffic by IP, add the Airbyte Cloud IP addresses to the relevant allow list before you begin.

How do you build an Amplitude to BigQuery pipeline in Airbyte?

Step 1: Size the Request Time Range to your busiest day

The default asks for twenty-four hours at a time, which suits a modest project and fails on a large one. Work out what your heaviest day produces rather than your average, because a marketing campaign or a product launch is exactly when you least want the pipeline to stop. Shortening the range to six or twelve hours costs more requests and avoids the cap entirely, which is the right trade.

Step 2: Configure the Amplitude source

Click Sources in the left navigation, then New Source, and select Amplitude, following adding a source. Supply the API key, secret key, start date, data region and your chosen time range. The dashboard REST API streams work against a cost-based budget which the connector throttles itself against, so those need no tuning from you.

Step 3: Configure the BigQuery destination

Click Destinations, then New Destination, and select BigQuery, following adding a destination. Supply the project identifier, dataset and service account credentials. Event volumes are one of the few cases where Cloud Storage staging earns its keep over batched standard inserts, so consider it if your daily counts are large.

Step 4: Create the connection and plan the backfill separately

Click Connections, then New connection, select your streams and a sync mode. Treat the historical backfill as a separate exercise from the ongoing sync, since a year of events at four gigabytes per export is a lot of exports and it will take as long as it takes. Set the start date deliberately rather than reaching for everything by reflex.

Tables arrive partitioned daily on the extraction timestamp and clustered on that with your primary keys, so teach people to filter on the partitioning column as well as on event time, or every query reads the whole table.

Why does your export fail, or worse, hang?

Because the export API caps each export at four gigabytes, and the two ways of meeting that limit feel very different. Go past it and you get an error, which is annoying and at least clear. Approach it and the request times out instead, which looks like a network problem and sends people investigating entirely the wrong thing.

The Request Time Range is the only real lever. Asking for twelve hours rather than twenty-four halves the payload, six hours quarters it, and each request is small enough to complete. More requests is the cost, and it is a much better problem than a sync that neither succeeds nor fails cleanly.

Size it against growth as well as today. Event volume rises when the product succeeds, so a range that comfortably fits now will not in a year, and the failure arrives during whatever growth caused it. Reviewing this figure occasionally is cheaper than diagnosing a timeout during a launch week.

Why does geography matter at both ends of this pipeline?

Because Amplitude and BigQuery each have a notion of where data lives, and they have to agree. An Amplitude project on EU residency is readable only through the residency server, and a BigQuery dataset has a location fixed at creation that can never be altered afterwards.

Get the Amplitude end wrong and it fails immediately, which is the good outcome. Get the BigQuery end wrong and everything works: data lands, queries run, nobody notices, and the problem surfaces months later either as a compliance question nobody can answer comfortably or as a join that BigQuery refuses because the two datasets sit in different locations.

So settle three things in one conversation before creating anything: which region the Amplitude project uses, where the data you intend to join already sits, and whether any residency obligation applies to behavioural data about your users. Then create the dataset in the location that satisfies all three. It is ten minutes at the start and a full rebuild afterwards, because the only remedy for a dataset in the wrong place is another dataset and another sync.

Frequently asked questions

My sync times out rather than failing. Why?

You are approaching the four gigabyte export cap. Exceeding it errors, but getting close times out instead, so shorten the Request Time Range rather than looking for a network fault.

Our project is on EU residency. Does that change anything?

Yes, you must point the source at the residency server. It also makes the BigQuery dataset's location a decision worth checking against whatever obligation put the project on EU residency.

Can one source cover several Amplitude projects?

No, credentials are per project, so each one needs its own source. Give them separate datasets or clearly separated tables so nobody merges two projects by accident.

Do I need to throttle the dashboard streams?

No. Those use a cost-based budget that the connector manages itself, so the export cap is the constraint that needs your attention rather than those.

Can I do this without writing code?

Yes, the setup is entirely UI-driven. The judgement involved is sizing the time range and choosing the dataset location, both of which are decisions rather than code.

Get your Amplitude data into BigQuery

Size the Request Time Range against your busiest day rather than your average, since a timeout is what approaching the cap looks like. Confirm the Amplitude region rather than assuming it. Create the BigQuery dataset in a location that satisfies your joins and any residency obligation at the same time, because that choice is permanent and failing it is silent. Then teach people to filter on the partitioning column so the queries stay affordable.

Airbyte's connector catalog includes 600+ pre-built connectors, so product behaviour can sit beside the commercial data that gives it meaning. For the same source into a column store, see Amplitude to ClickHouse, and for a comparable product analytics tool into the same destination, Mixpanel to BigQuery.

Start syncing now →