Metabase to BigQuery: How to Move Your Data

Moving Metabase into BigQuery is a governance pipeline rather than a data one, and being clear about that first saves a wasted project. Metabase sits on top of your databases, so this connector does not give you the results of your questions. It gives you the catalogue: which cards exist, which dashboards use them, who owns what.

That is genuinely useful once a BI estate reaches the size where nobody can describe it. This guide covers the managed path with Airbyte, and an authentication trade-off that is more awkward than most and worth deciding deliberately.

Metabase to BigQuery at a glance:

Why move data from Metabase to BigQuery?

Two situations account for most of these pipelines.

The first is BI sprawl. Any Metabase instance a few years old contains hundreds of saved questions, most of which nobody has opened since the quarter they were made. Knowing which cards sit on dashboards, which collections are abandoned and who created what is how you clean that up without deleting something important.

The second is dependency mapping. Cards carry their queries, so you can find which ones touch a table you plan to change, which is a question people usually answer by making the change and waiting for complaints. If instead you want the numbers a dashboard shows, query the underlying database directly.

What do you need before you start?

The list is short and one item deserves a proper decision rather than a default:

Your instance API URL. The address Airbyte uses to reach your Metabase API, over HTTPS. On a self-hosted instance this is your own server rather than a vendor domain. The Metabase source documentation covers the fields.

A decision between a session token and a credential pair. Both work and neither is clean. A session token usually expires after fourteen days and needs replacing. Username and password alone means a new session is generated every time an authenticated query runs, which is covered below.

An account whose visibility covers what you want. Metabase permissions govern which collections and cards an account can see, so the account behind this pipeline determines the completeness of your catalogue. An administrator account gives the full picture, which for a governance dataset is usually the point.

A BigQuery service account and dataset. With the BigQuery User and BigQuery Data Editor roles. Volume is never a concern here, since even a large Metabase instance amounts to a few thousand rows.

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 Metabase to BigQuery pipeline in Airbyte?

Step 1: Settle the authentication approach

Decide whether you will supply a session token and rotate it, or supply credentials and accept the session churn. If you self-host Metabase there is a third option, since session duration is configurable on your own server, which makes the token route considerably more practical.

Step 2: Configure the Metabase source

Click Sources in the left navigation, then New Source, and select Metabase, following adding a source. Supply the instance API URL and your chosen credentials. A session token is obtained by posting your username and password to the session endpoint, which returns an object whose identifier is the token value.

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. Batched standard inserts is the default and is more than enough, since this dataset is small however large your Metabase instance feels to use.

Step 4: Create the connection and schedule slowly

Click Connections, then New connection, select your streams and a sync mode. Cards, collections, dashboards, users and databases together give you the whole catalogue. Daily or even weekly is plenty, because a BI estate changes at the speed of people creating dashboards rather than continuously.

That slow schedule is not just tidiness. If you authenticate with credentials alone, every authenticated query opens a session, so syncing less often is directly fewer sessions and fewer notifications.

Why is the authentication choice awkward?

Because both routes have a real cost. Supply a session token and it usually expires after fourteen days, at which point the connector raises errors about invalid and expired tokens and requests come back unauthorised. Nothing renews it for you, so the pipeline needs a person on a fortnightly rota.

Supply only a username and password and the connector generates a session token every time an authenticated query runs. Metabase may send an email to the account owner each time a new session is opened, and the documentation warns that this might trigger security alerts on the account. A pipeline that quietly generates security notifications is a pipeline somebody will eventually switch off.

If you host Metabase yourself there is a way out, because session duration is configurable on your server through an environment variable measured in minutes. Extending it makes the token route practical rather than a fortnightly chore. On a hosted instance, pick your poison deliberately and put the rotation in a calendar rather than trusting anyone to remember.

What can you actually answer with this?

More than the stream list suggests, because the pieces join up. Cards carry their metadata, parameters and the query itself. Collections group them and carry permission settings. Dashboards reference the cards they display. Users tell you who created what, and databases record which connections exist.

Join those and you can find cards belonging to no dashboard, collections nobody has touched, dashboards whose creator has left, and every card querying a particular table. That last one is the query most worth building, because a migration plan that knows what will break is a different conversation from one that does not.

One limitation to be honest about. This is the catalogue rather than usage, so it tells you what exists and not what anyone looks at. Whether a dashboard is actually opened is a question for Metabase's own usage analytics, and the two together are considerably more useful than either alone.

Frequently asked questions

Does this give me the data behind my dashboards?

No. It gives you metadata about cards, collections, dashboards, users and databases. For the numbers themselves, query the underlying database Metabase connects to.

My sync started returning unauthorised errors. What happened?

Your session token expired, which usually happens after about fourteen days. Generate a new one and update the connector configuration.

Why is Metabase emailing the account owner?

Because supplying only a username and password causes a new session to be opened for each authenticated query, and Metabase may notify the owner each time. Supply a session token instead, or sync less often.

Can I make the session token last longer?

On a self-hosted instance, yes. Session duration is configurable on your Metabase server through an environment variable measured in minutes.

Can I do this without writing code?

Yes. The setup above is UI-driven, apart from one command to generate a session token if you choose that route. You will want BigQuery views joining cards to dashboards and collections.

Get your Metabase data into BigQuery

Confirm this is the catalogue rather than the numbers, choose your authentication route knowing both have a cost, use an account whose visibility covers the whole estate, and schedule weekly rather than hourly. Then build the view that finds every card querying a given table, because that is the one people will thank you for.

Airbyte's connector catalog includes 600+ pre-built connectors, so your BI catalogue can sit beside the systems it describes. For another governance-shaped source, see Microsoft Teams to Databricks, and for delivery metadata in the same warehouse, GitLab to BigQuery.

Start syncing now →