Airtable to BigQuery: How to Move Your Data
Move Airtable into BigQuery with Airbyte. Why renaming a table stops the sync, the per-base rate limit, and choosing stream naming before the first sync.
Moving Airtable into BigQuery takes data that a person maintains by hand and puts it somewhere a query engine can reach. That is genuinely valuable, because the base someone updates every week is often the only place a piece of business context exists. The usual alternative is a CSV export, which is a snapshot rather than a pipeline.
This guide covers the managed path with Airbyte. The thing to understand before you build it is that your upstream is a human being with edit rights, and the connector has one behaviour in particular that turns an ordinary Airtable tidy-up into a silently broken sync.
Airtable to BigQuery at a glance:
Why move data from Airtable to BigQuery?
Two situations account for most of these pipelines.
The first is joining hand-maintained context to system data. Account tiers, campaign metadata, territory assignments, a list of strategic customers. These live in Airtable because a person curates them, and they are exactly what your warehouse tables lack. A join between the two answers questions neither side can answer alone.
The second is scale and history. Airtable is pleasant up to a point and its views are not a reporting layer. Once someone wants a year of trend analysis or a join across three bases, a warehouse is the answer. If you only need the current contents of one table for a dashboard, an Airtable view is simpler and this pipeline is unnecessary.
What do you need before you start?
The setup is short. The agreement with whoever owns the base is the part that matters:
OAuth or a personal access token. OAuth is recommended on Airbyte Cloud, where you authorise the workspaces you want to sync. With a personal access token you select the required bases when creating it. Either way, grant access to the bases you actually intend to replicate rather than everything available. The Airtable source documentation covers both.
An agreement about renaming. If a table is renamed in Airtable after syncing has started, the connector stops syncing it until you reset the connection schema and select it again. This is the single most likely way this pipeline breaks, and it breaks quietly.
A decision on stream naming, made now. If you sync cloned bases containing tables with the same name, enable the option to include the base ID in stream names. Enabling it later changes stream names and requires a full refresh, so decide at setup rather than after.
A BigQuery service account and dataset. With the BigQuery User and BigQuery Data Editor roles. Set the dataset location to match whatever you intend to join against, since it cannot be changed after creation.
One note on OAuth: the documentation flags that you may see a 400 or 401 error causing a failed sync when using it. If that happens, re-authenticating is the first thing to try before assuming a deeper problem.
How do you build an Airtable to BigQuery pipeline in Airbyte?
Step 1: Talk to whoever owns the base
Tell them that table names are now an interface, and that renaming one stops it syncing until someone intervenes in Airbyte. This is not a technical step and it is the one that determines whether the pipeline is still working in six months. Agree who to tell before renaming or restructuring, and write it in the base description where they will see it.
Step 2: Configure the Airtable source
Click Sources in the left navigation, then New Source, and select Airtable, following adding a source. Choose OAuth or personal access token authentication and authorise the workspaces or bases you need. Decide the base ID naming option here, before the first sync, since changing it afterwards forces a full refresh.
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 loading method and is ample here, because an Airtable base is small by warehouse standards and this is not a high-volume pipeline.
Step 4: Create the connection and tune concurrency
Click Connections, then New connection, select your tables and a sync mode. If you are syncing several bases, raise the concurrent threads setting from its default of 5, which is adjustable between 2 and 40. Higher values improve performance across multiple bases, and the connector automatically respects Airtable's limit of 5 requests per second per base, so increasing it will not produce rate limit errors.
That per-base limit is the useful detail. Because it applies per base rather than per account, syncing ten bases has roughly ten times the available throughput of syncing one, which is why concurrency helps in exactly the situation where you would expect it to hurt.
Why does renaming a table break the sync?
Because the connection tracks the table by the name it had when you selected it. Rename it in Airtable and the connector will not continue syncing that table until you reset the connection schema and select it again. At that point it begins syncing to a table with the new name in the destination.
Two things make this worse than it sounds. Nothing errors loudly, so the symptom is a warehouse table that quietly stops receiving updates while everything reports as healthy. And the recovery produces a differently named destination table, so any downstream model or dashboard referencing the old one needs updating too.
The practical defences are a conversation with the base owner, a note in the base itself, and a freshness check on the destination table so a stalled sync surfaces within a day rather than when someone notices the numbers look old. On any pipeline whose upstream is a person, that last one is worth having regardless.
What if two bases have tables with the same name?
This is common, because cloning a base is how most teams create the next quarter's or the next region's version of something. The result is several tables called Projects or Contacts across different bases, all wanting the same stream name.
The connector offers an option to include the Airtable base ID in stream names, which guarantees uniqueness. It is the right answer whenever you sync cloned bases, and it costs you readability, since a stream named after a base ID is less obvious than one named Projects. A view in BigQuery with a friendly name solves that.
Decide at setup. Enabling the option changes stream names and requires a full refresh of your data, so turning it on six months in means re-reading everything and repointing whatever was querying the old names. On a small Airtable base the refresh itself is cheap; the downstream repointing is what costs you.
Frequently asked questions
My table stopped syncing after someone renamed it. What now?
Reset the connection schema and select the table again. It will then sync to a table with the new name in the destination, so update any downstream models that referenced the old one.
Will raising concurrent threads cause rate limit errors?
No. The connector automatically respects Airtable's limit of 5 requests per second per base, so increasing the thread count above the default of 5 improves throughput without tripping the limit.
How do I handle tables with the same name in different bases?
Enable the option to add the base ID to stream names, and do it at setup, because enabling it later changes stream names and requires a full refresh.
Should I use OAuth or a personal access token?
OAuth is recommended on Airbyte Cloud. If you see a 400 or 401 error causing a failed sync, re-authenticate before assuming something deeper is wrong.
Can I do this without writing code?
Yes. The setup above is entirely UI-driven, from creating the source through to scheduling the connection. If you would rather manage pipelines as infrastructure, the same objects can be provisioned from configuration files instead.
Get your Airtable data into BigQuery
The technical work here is small and the social work is not. Decide the stream naming option at setup, raise concurrency if you sync several bases, add a freshness check on the destination tables, and have the conversation about renaming before it happens rather than after.
Airbyte's connector catalog includes 600+ pre-built connectors, so hand-maintained context can sit alongside your system data. For another source whose upstream is a person, see Smartsheet to Databricks, and for Airtable into a relational destination, Airtable to PostgreSQL.
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.