Postgres to BigQuery loads with schema mapping and incremental sync

Read rows past an indexed updated_at watermark, stage them, then MERGE into the target table on the primary key. Full reloads are simple but expensive once tables get large, and they scale badly. Incremental loads keep both the runtime and the query bill flat.

Through federated queries with EXTERNAL_QUERY, and only for Cloud SQL instances, not any PostgreSQL server you happen to run. For a self-managed or third-party hosted Postgres, something has to extract and load the rows, which is what a scheduled connector does.

Integers become INT64, numeric keeps its precision as NUMERIC, text becomes STRING, boolean stays BOOL, jsonb becomes JSON, and timestamptz becomes TIMESTAMP normalized to UTC. Money columns belong in NUMERIC rather than FLOAT64, since FLOAT64 cannot represent cents exactly.

BigQuery bills by bytes scanned, so partition large tables on the date column analysts filter by and cluster on the columns they group by. An unpartitioned copy of a big table turns a cheap daily dashboard into a recurring line item nobody budgeted for.

The Postgres to BigQuery pipeline from Adapters loads tables incrementally into your warehouse with schema mapping, type casting, and automatic retries, at a flat monthly price instead of per-row usage billing. It reads changed rows on a watermark so each run stays cheap and no code is required.

Yes. This Postgres to BigQuery connector ships prebuilt: the field mapping is wired the moment you pick the pair, transforms are included, and the first sync can run within minutes. No code or engineering sprint required.

Pricing is flat and monthly: Starter at $49, Growth at $149, Scale at $399. Every plan includes this pair, visual field mapping, and per-record logs. There are no per-task or per-row fees, so the bill stays the same as volume grows.

Hourly on Starter, every 5 minutes on Growth, and down to every minute on Scale. Failed records retry automatically with backoff, and alerting plus a full per-record log come standard on every run.

No. Fields are auto-mapped the moment you pick the pair, and you can rewire any mapping visually before the first sync. Incremental loads read rows past an updated_at watermark so each run only moves what changed; Postgres types cast to BigQuery types (numeric to NUMERIC, jsonb to JSON, timestamptz to TIMESTAMP in UTC), cents convert to decimal amounts, and tables partition and cluster so queries scan less and cost less.