Google Ads to PostgreSQL: How to Move Your Data
Move Google Ads into PostgreSQL with Airbyte. Why the conversion window keeps restating recent days, and how custom queries decide your tables.
Moving Google Ads into PostgreSQL suits software that needs campaign figures beside your own data. A budget pacing tool, an internal dashboard or a service that pauses spend when a product goes out of stock all want those numbers where the application reads.
This guide covers the managed path with Airbyte. Two things shape the build: recent figures keep changing for days after the fact, and the queries you write decide both your tables and whether this destination can hold them.
Google Ads to PostgreSQL at a glance:
Why move data from Google Ads to PostgreSQL?
One situation genuinely suits this, and the other is worth naming.
The good case is serving software. A tool pacing budgets, a dashboard showing today's spend against targets or a service reacting to performance all need current figures beside your own records, which a relational database holds cheaply.
The poor case is analysis across years of keyword-level reporting, which outgrows this destination quickly. For attribution work and long history, Google Ads to BigQuery is the right home and costs you far less trouble.
What do you need before you start?
Four things, and the second catches out anybody using a manager account:
A developer token and OAuth credentials. Obtained through the Google Ads API centre, which is its own approval process rather than a setting. The Google Ads source documentation covers the sequence.
The right customer ID. If you reach the account through a manager account, you must supply the manager's customer ID, and using the client account's instead produces a permission error that does not explain itself.
Queries narrow enough for this destination. Campaign-level daily figures are modest; keyword-level reporting across a large account is not, and guidance here is around ten gigabytes.
An agreed conversion window. It decides how long figures keep moving after a day ends, which matters more when software is reading them than when a person is.
If your database restricts inbound traffic by IP, add the Airbyte Cloud IP addresses to the allow list before you begin.
How do you build a Google Ads to PostgreSQL pipeline in Airbyte?
Step 1: Set the conversion window from how your business counts
Decide the window with whoever owns the marketing numbers, because it determines how long a day's figures keep changing and therefore when your software can treat them as settled. A long window gives a truer picture of what advertising produced and a longer period of movement; a short one settles quickly and undercounts late conversions. Neither is wrong and the choice should be deliberate.
Step 2: Configure the Google Ads source
Click Sources in the left navigation, then New Source, and select Google Ads, following adding a source. Authenticate, supply the developer token and customer IDs, remembering the manager account rule, then set the conversion window and define any custom queries in Google Ads Query Language.
Step 3: Configure the PostgreSQL destination
Click Destinations, then New Destination, and select PostgreSQL, following adding a destination. Supply the host, port, database and credentials, and give this its own schema. Expect metadata columns to be added, so application code should select fields by name.
Step 4: Create the connection and index for the tool
Click Connections, then New connection, select your streams and a sync mode. Use a deduplicating mode, since the conversion window means recent days arrive repeatedly. Then create indexes on the date and campaign columns your software filters by.
Remember to refresh the source schema after editing custom queries or upgrading the connector, since both can change what the streams contain.
Why do yesterday's figures keep moving?
Because a conversion is recorded against the day of the ad interaction rather than the day it happened. Somebody clicks on Monday and buys on Thursday, and Monday's conversion count goes up on Thursday, so each sync retrieves all conversions active within your configured window and restates what it finds.
That is correct behaviour and awkward when software is reading the table. A tool that computed a cost per acquisition on Tuesday and acted on it has used a figure that was always going to change, and a report emailed each morning will disagree with itself a week later without anybody having made a mistake.
So make the settling period explicit in whatever reads this. Mark days inside the window as provisional, have automated decisions use data older than the window, and if a figure is shown to a person, show how recent it is. The alternative is a tool that acts confidently on numbers that have not finished arriving.
How do your queries decide your tables?
Directly, because custom queries written in Google Ads Query Language become additional streams, each producing its own table. That is unusually flexible for a marketing connector and it moves a design decision to you: what a row represents is whatever your query selected.
For this destination that flexibility is also the volume control. A query returning campaign totals by day is a small table that will stay small; the same query at keyword level across a large account multiplies by every term you bid on, and a database sized for around ten gigabytes notices. Write queries for what the software displays rather than for completeness.
Treat them as configuration with consequences. Editing or removing a query means refreshing the source schema afterwards, and connector upgrades following Google's API versions have changed schemas before, requiring the same. So keep the queries under version control if you can, and check your tables after any upgrade rather than assuming continuity.
Frequently asked questions
Why do historical numbers change?
Conversions are attributed to the interaction date, so each sync re-reads the conversion window and restates recent days. Treat days inside the window as provisional.
I get a permission error on a valid account.
If you reach the account through a manager account, the manager's customer ID is required. The error message does not usually say so.
My table is growing faster than expected.
Your query is probably too granular. Keyword-level daily reporting multiplies quickly, and this destination is comfortable with campaign-level figures.
I edited a custom query and the data looks wrong.
Refresh the source schema after changing or removing queries. The same applies after connector upgrades that follow a Google Ads API version change.
Can I do this without writing code?
The pipeline, yes, though custom queries are written in Google's query language. The indexes and the provisional-data logic in your tool are yours.
Get your Google Ads data into PostgreSQL
Agree the conversion window with whoever owns the numbers, because it decides when figures stop moving and your software needs to know that. Supply the manager account's customer ID if that is how you connect. Then write queries for what the tool displays rather than for completeness, index what it filters on, and refresh the schema whenever a query or the connector changes.
Airbyte's connector catalog includes 600+ pre-built connectors, so advertising figures can reach the software that acts on them. For the same source into a warehouse, see Google Ads to BigQuery, and for a collaborative source into the same destination, Airtable to PostgreSQL.
Integrate with 700+ apps using Airbyte
Move data from 700+ sources into warehouses, lakes, and beyond. Set up pipelines in minutes with pre-built connectors and the Connector Builder.