Connect Google Maps to PostgreSQL
Turn a list of addresses into latitude and longitude, or coordinates back into addresses, with the parsed components split into their own columns. Geocoding only — this is not a Places or routing connector.
What you can pull from Google Maps
Google Maps exposes 1 object you can pull, each as its own job. Every run pulls the records into a flat table, so nested fields arrive as ordinary columns that PostgreSQL can sort, filter and total without further work.
Geocoding results
One row per input. The input address is echoed back verbatim so the frame can be joined onto whatever you sent, and the address components are split into their own columns rather than left as one string.
| Column | Type | Notes |
|---|---|---|
| input_address | string | Echoed verbatim, so results join back onto your input |
| status | string | OK or ZERO_RESULTS are normal per-row answers, not failures |
| formatted_address | string | — |
| latitude | float | — |
| longitude | float | — |
| place_id | string | — |
| location_type | string | ROOFTOP, RANGE_INTERPOLATED, GEOMETRIC_CENTER or APPROXIMATE |
| locality | string | — |
| postal_code | string | — |
| administrative_area_level_1 | string | — |
| country | string | — |
| country_code | string | — |
| partial_match | boolean | Google matched something, but not confidently |
Options you can set
- mode
- 'forward' geocodes addresses into coordinates; 'reverse' turns lat/lng pairs into addresses — defaults to
forward - components
- Component filter, e.g. country:GB|postal_code:SW1. Narrows results without making the address more specific
- region
- ccTLD region bias, e.g. gb - influences ambiguous place names
- language
- Language for returned addresses
- rate_per_second
- Outbound request pacing, up to 50 — defaults to
10 - on_row_error
- fail_fast, or continue past a transient per-row failure — defaults to
fail_fast
How it lands in PostgreSQL
PostgreSQL accepts append, replace, upsert writes. Upsert is the one that matters on a schedule: it merges on a key you choose, so matching rows are updated in place and only genuinely new records are created. Append instead, and a daily job multiplies your data.
Upsert uses key_columns as the conflict target.
- Rows are written in chunks of 1,000 by default, configurable up to 50,000.
- Replace truncates the target table before writing.
Authentication
Google Maps authenticates with an API key held as a stored connection, so it never appears in a spreadsheet cell, a formula, or a shared copy of a sheet.
Keeping runs incremental
Not for this source: Each run geocodes the inputs it is given. Where that is expensive, narrow the job itself and run it less often.
Pair a narrowed read with an upsert write and a re-run costs almost nothing: the rows it already knows are updated, and nothing is duplicated. That combination is what makes a frequent schedule affordable.
Limits and pacing
These are the provider-side ceilings that shape a schedule, not ours. Knowing them up front is the difference between a job that runs quietly every morning and one that starts failing the week your data grows.
| Limit | Value | Applies to |
|---|---|---|
| Inputs per run About 25 seconds at the default pacing, and it keeps the per-run bill bounded on an API that charges per request. | 250 | Google Maps |
| Request pacing Defaults to 10. | up to 50/second | Google Maps |
Common gotchas
Most of what goes wrong with a scheduled sync is not a bug — it is a detail of how one side behaves that nobody wrote down. These are the ones that come up for this pair.
ZERO_RESULTS is an answer, not an error
An address Google cannot place returns a row with status ZERO_RESULTS rather than failing the run. Filter on status before you trust the coordinates.
partial_match means "close enough, probably"
Google matched something but was not confident. On a list of user-typed addresses these are the rows worth reviewing by hand.
Capped at 250 inputs per run
For a larger backlog, batch it across scheduled runs rather than expecting one job to geocode everything.
Set either table or query, never both
The config rejects both being set, and rejects neither - caught when the job is saved rather than on its first run.
Set it up in four steps
- 1
Connect Google Maps
Your own Google Maps API key, stored as a connection. Billing and quota are yours, on your Google Cloud project.
- 2
Connect PostgreSQL
Host, port, database, user and password, stored encrypted.
- 3
Shape the data
Select the columns you want, filter rows, cast types and add computed fields. Everything else is dropped before it reaches the destination.
- 4
Schedule it
Run once, or on a cron. Every run refreshes PostgreSQL with the latest Google Maps data.
Do I need an add-on or extension for this?
No. The job runs server-side and writes into PostgreSQL through its API, so there is nothing installed in the destination itself. It keeps running when nobody has the file open, and a copy of the file does not need anything installed to work.
How often does the data refresh?
On whatever schedule you set with a cron expression — hourly, daily, or a specific time on specific days. Each run pulls the latest from Google Maps.
Do I need to write any code?
No. You connect both sides, map the fields in a wizard and set a schedule. Computed fields accept small expressions — abs, round, min, max, len — but there is nothing to host or maintain.
Who pays for the geocoding?
You do, on your own Google Cloud project, with your own key. Maps charges per request, which is why a run is capped at 250 inputs rather than being allowed to run away.
Can it look up businesses or directions?
No. This is the Geocoding API only - addresses to coordinates and back. Places and routing are deliberately out of scope.
Can I run my own SQL rather than reading a table?
Yes. Set a query instead of a table and aggregate in the database, which is usually far cheaper than moving raw rows and aggregating downstream. One statement only - multi-statement queries are rejected.
Does it need a superuser?
No. A user with SELECT on what you are reading is enough for a source; a destination needs INSERT and, for upsert, UPDATE on the target table.
Is the Google Maps connector free to use?
You can connect Google Maps and start syncing on the free plan.
Other sources into PostgreSQL
Related reading
Airtable upsert: stop creating duplicate records
Appending on every run turns a tidy base into six copies of every row. Here is how upsert works in Airtable, and how to choose a merge key that holds up.
Get data into Google Sheets without an add-on
Every major Sheets data tool is an add-on you install, authorise and keep updated inside the spreadsheet. Here is how to schedule the same imports without one.
Mailchimp campaign reports in Airtable
Mailchimp's reporting lives one campaign at a time. Here is how to get opens, clicks and bounces for every campaign into Airtable, updating on a schedule.