Question 1

How do I replicate Postgres to BigQuery?

Accepted Answer

Connect both sides, pick your tables, set a schedule. Polytomic loads everything once, then follows PostgreSQL logical replication for changes. On the Postgres side you need a publication covering those tables, a replication slot, and wal_level set to logical. The connecting user needs the REPLICATION attribute, or rds_replication on RDS, plus SELECT. On the BigQuery side you need a service account with Job User and Data Editor rights, and nothing else.

Question 2

What happens in BigQuery when a Postgres column changes type?

Accepted Answer

The sync keeps running rather than breaking. If the new type is not compatible with the existing column, the old column is renamed to a deterministic archived name with its previous type appended, and a fresh column with the original name and new type is created next to it. You keep the historic values and get the new ones, and nothing needs fixing by hand. New columns are simply added. Dropped source columns stay in BigQuery rather than being removed, so old fields linger until you clear them.

Question 3

Can I partition the BigQuery table by a Postgres timestamp?

Accepted Answer

Yes. Each destination table can use one datetime field as its time partition key, which matters a lot on large event tables since it decides how much data a filtered query has to scan. Newer syncs default to monthly partitions. One thing to plan for: BigQuery cannot repartition a table in place, so changing the key or the cadence later means recreating the table with a resync and rebuild. An ordinary incremental run will not do it.

Question 4

Do deletes from Postgres reach BigQuery?

Accepted Answer

With logical replication, yes. The delete arrives as an event and the merge marks the row with a deleted at timestamp, keeping it visible to anything that wants to count what has gone. Switch on propagate hard deletes and those rows are removed for real afterwards. The catch is that the fallback read paths behave differently. A tracking column read and an xmin read both simply stop returning the row, so pair either with a periodic full read.

Question 5

Is BigQuery a good target for replicating an application database?

Accepted Answer

It suits it well, for two reasons people mention often. Setup is light, since there is no staging storage to manage, and the project model gives you clean isolation, which is why teams running per customer analytics tend to land on BigQuery. The general argument applies too: heavy aggregations do not belong on the server running your product, and the CRM or billing data you want to join to was never in Postgres. ETL moves that load somewhere it belongs.

Sync PostgreSQL to BigQuery

Sync PostgreSQL to BigQuery with Polytomic

Deletes travel as events

Partition on a timestamp

Type changes handled

Or sync BigQuery to PostgreSQL

Trusted by businesses worldwide

Step-by-step integration guide

Connect PostgreSQL in Polytomic

Connect BigQuery in Polytomic

Create a sync between PostgreSQL and BigQuery

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 PostgreSQL with BigQuery?