Question 1

Why push BigQuery results into Postgres?

Accepted Answer

Because the things that need the answer often cannot query a data warehouse. An internal admin tool, a service that gates a feature on plan tier, or a customer facing view all read from the application database, and pointing them at BigQuery is either too slow or not permitted. Reverse ETL puts the modelled result where those systems already look, refreshed on a schedule rather than by a script someone has to remember to maintain.

Question 2

How do I keep the BigQuery side cheap?

Accepted Answer

By reducing what each run scans, since on demand pricing bills for bytes read multiplied by how often you run. Set a tracking field, which incremental reads need alongside a unique identity on the table, then partition and ideally cluster the source so that predicate actually prunes data. Select only the columns you map and avoid views or custom SQL that defeat partition pruning. An optional Extract mode can read large bulk syncs through a Cloud Storage bucket in parallel, which improves throughput but does not reduce the bytes BigQuery scans.

Question 3

Do deletes in BigQuery reach Postgres?

Accepted Answer

It depends on how the sync reads. With a tracking field configured, no: the query only returns rows whose tracking value advanced, so a deleted row stops appearing rather than being marked for deletion downstream, and a row edited without that value moving is missed for the same reason. Without a tracking field, a full scan can identify rows that have gone and propagate deletes according to the destination's settings. That trade between cost and delete accuracy is the real decision here.

Question 4

How does the write behave?

Accepted Answer

Model syncs write directly with no staging table, batching inserts and issuing updates per row, and a failed batch is retried row by row so errors point at specific records. Bulk table replication behaves differently and stages into a scratch table before merging, so readers never see a partially written result. Modes are create, update, update or create, and replace, with replace clearing the whole target table rather than removing only the rows missing from your query.

Connect BigQuery with PostgreSQL

Connect BigQuery and PostgreSQL with Polytomic

Storage Read API

Tables created for you

No target key required

Trusted by businesses worldwide

Step-by-step integration guide

Connect BigQuery in Polytomic

Connect PostgreSQL in Polytomic

Create a sync between BigQuery and PostgreSQL

Map fields and enable the sync

Frequently asked questions

The sync and ETL platform that does it all

Powerful data sync

Advanced analytics

Enterprise security

Easy setup

Ready to connect BigQuery with PostgreSQL?