Como Sincronizar PostgreSQL com o BigQuery Automaticamente

O PostgreSQL é onde a aplicação escreve; o BigQuery é onde os analistas consultam. Levar dados de um pro outro sem depender de alguém clicando manualmente significa escolher entre uma sincronização batch agendada e CDC. Este guia percorre todas as opções, com os limites e preços de cada uma.

Como sincronizar PostgreSQL com o BigQuery automaticamente?

Você pode agendar uma sincronização incremental em batch ou rodar change data capture (CDC) em cima do write-ahead log. Uma sincronização agendada funciona bem quando os dados podem ter algumas horas de atraso. Já o CDC leva inserções, atualizações e exclusões para o BigQuery em poucos minutos.

Os dois funcionam de formas diferentes. Uma sincronização agendada consulta a tabela de origem periodicamente, usando uma coluna de referência (watermark) como updated_at para pegar só as linhas que mudaram desde a última execução. O CDC não faz consultas. Ele lê o write-ahead log (WAL) — o arquivo onde o PostgreSQL registra cada mudança antes de aplicá-la — e transmite essas mudanças direto para o destino.

A diferença que mais importa é a exclusão. Uma linha excluída simplesmente para de aparecer nas consultas, então uma sincronização agendada nunca a vê, e a linha fica no BigQuery para sempre. Já uma exclusão é registrada no WAL, então o CDC a captura e remove a linha também no BigQuery.

Quais são todas as formas de replicar PostgreSQL para o BigQuery?

São cinco: o BigQuery Data Transfer Service para batch agendado, o Google Datastream para CDC, uma ferramenta ELT gerenciada (extract, load, transform) como a Erathos, uma exportação manual para o Cloud Storage com cargas agendadas, ou Debezium com Kafka. As duas primeiras são nativas do Google; as duas últimas você constrói e opera sozinho.

O Cloud Data Fusion Replication suporta fontes MySQL, SQL Server e Oracle, então está fora de cogitação para PostgreSQL.

O BigQuery Data Transfer Service suporta PostgreSQL?

Sim. O BigQuery Data Transfer Service tem um conector pago para PostgreSQL que roda transferências recorrentes no agendamento que você definir. As transferências incrementais estão em Preview, aceitam só colunas TIMESTAMP como watermark, e não sincronizam exclusões.

Se algum tutorial disse que o serviço não tem conector para PostgreSQL, está desatualizado. Você cria uma configuração de transferência no console com o host, as configurações de TLS, as tabelas a mover e um agendamento, e o BigQuery puxa os dados nesse ritmo, sem você precisar manter um scheduler próprio.

Os limites são específicos. Transferências completas recarregam a tabela inteira a cada execução. Transferências incrementais precisam de uma coluna TIMESTAMP como watermark que só cresce, e um upsert também exige uma chave primária. Tabelas sem chave primária ou coluna indexada não podem mover mais de 2.000.000 de registros. Se uma execução ainda estiver rodando quando a próxima estiver agendada, a nova execução é pulada.

O custo é medido em slot-hours, a unidade de computação que o BigQuery usa para cobrar transferências. A orientação de planejamento do Google é de até 20 slot-hours para cada hora que uma transferência roda, o que dá cerca de US$ 1,20 por hora em us-central1.

Quando você deveria usar o Google Datastream em vez disso?

Use o Datastream quando você precisa de exclusões e de dados atualizados na casa dos minutos, sem depender de uma ferramenta de terceiros. Ele lê o WAL do PostgreSQL através de um replication slot e escreve as mudanças no BigQuery em modo Merge, mantendo as tabelas de destino sincronizadas com a origem.

A configuração envolve criar um perfil de conexão para o PostgreSQL, outro para o BigQuery, e depois um stream que define o replication slot e a publication na origem. Você escolhe um limite de defasagem (staleness); o padrão do quickstart é 15 minutos. Quanto menor a defasagem, mais vezes o BigQuery roda jobs de merge — e esses jobs são cobrados como computação normal do BigQuery.

O Datastream tem pontos delicados em torno de chaves primárias. Tabelas sem chave primária viram append-only: cada mudança chega como uma linha nova, com metadados, em vez de atualizar a linha existente. Tabelas cuja chave primária é do tipo FLOAT ou REAL são simplesmente ignoradas. Toda tabela replicada também ganha uma coluna datastream_metadata, e cada evento tem um limite de 20 MB.

O que você precisa configurar no PostgreSQL antes de o CDC começar?

Quatro configurações de servidor, uma role com permissão de replicação, uma publication e um replication slot. A configuração é a mesma independente de o consumidor ser o Datastream, a Erathos, o Airbyte ou o Debezium.

Primeiro, as configurações de servidor:

sql

ALTER SYSTEM SET wal_level = 'logical';
ALTER SYSTEM SET max_replication_slots = 10;
ALTER SYSTEM SET max_wal_senders = 10;
ALTER SYSTEM SET max_slot_wal_keep_size = '10GB';

As três primeiras só entram em vigor depois de um restart. A última é aplicada com um reload de configuração, sem precisar reiniciar. Por padrão, um replication slot retém WAL sem limite, então um consumidor pausado pode encher o disco da origem. Definir um limite troca esse risco por uma resincronização quando o limite é atingido.

Confira o resultado:

sql

SELECT name, setting FROM pg_settings
WHERE name IN ('wal_level', 'max_replication_slots',
'max_wal_senders', 'max_slot_wal_keep_size');

name | setting
------------------------+---------
max_replication_slots | 10
max_slot_wal_keep_size | 10240
max_wal_senders | 10
wal_level | logical

A view pg_settings reporta max_slot_wal_keep_size em megabytes, então 10240 é o equivalente aos 10GB que definimos. Depois, a role, a publication e o slot:

sql

CREATE USER sync_user WITH PASSWORD 'change-me';
ALTER ROLE sync_user WITH REPLICATION;
CREATE PUBLICATION bigquery_pub FOR TABLE orders;
SELECT pg_create_logical_replication_slot('bigquery_sync_slot', 'pgoutput');

A publication lista quais tabelas serão transmitidas. O slot é o "marcador" do lado do servidor que acompanha até onde o consumidor já leu, usando o pgoutput, o decoder nativo do PostgreSQL. Mais um comando importa quando a ferramenta precisa da linha antiga completa em updates e deletes, já que por padrão só a chave primária é registrada:

sql

ALTER TABLE orders REPLICA IDENTITY FULL;

A replica identity completa grava a imagem inteira da linha (antes da mudança) no WAL, então só faz sentido usar quando a ferramenta exige isso.

Amazon RDS, Cloud SQL, Supabase e Neon suportam CDC do PostgreSQL?

Os quatro suportam replicação lógica, então o CDC para o BigQuery funciona em todos. O que muda é o interruptor que você aciona, já que provedores gerenciados não deixam você editar o arquivo de configuração diretamente.

No Neon, um pipeline de CDC que você pausa por tempo demais perde o slot e precisa ressincronizar do zero.

Quais ferramentas gerenciadas sincronizam PostgreSQL com o BigQuery automaticamente?

Erathos, Fivetran, Airbyte e Estuary movem dados do PostgreSQL para o BigQuery sem precisar de código. Elas se diferenciam nos métodos de sincronização que oferecem, na velocidade e na unidade de cobrança.

Veja como as unidades de cobrança se comparam. As monthly active rows do Fivetran contam inserções e modificações, incluindo exclusões, e a primeira carga histórica é gratuita. A Erathos conta linhas escritas no destino, então um resync completo conta, mas uma tabela parada não custa nada. A Estuary cobra por volume movido mais o tempo ativo do conector.

Os planos da Erathos são cobrados por linhas escritas no data warehouse por mês

A escolha do método dentro de cada ferramenta também importa. O próprio guia do Airbyte diz que o modo xmin não captura exclusões e recomenda CDC para capturar deletes ou para bancos a partir de cerca de 500 GB.

Na Erathos, a configuração é rápida: conecte o PostgreSQL por conexão aberta, IP estático ou túnel SSH, escolha as tabelas, o agendamento (de 5 em 5 minutos até diário) e o tipo de atualização, e aponte para uma service account do BigQuery. Os modos batch e cursor nem passam pelo SQL de CDC. A Erathos detecta novas colunas na origem e as adiciona sozinha no BigQuery, e cada execução registra tempo de execução, contagem de linhas e erros, com alertas no Slack ou por e-mail. Todo conector tem 14 dias de trial gratuito.

Como as mudanças de CDC viram upserts e exclusões no BigQuery?

A ferramenta de sincronização mescla cada mudança na tabela de destino, usando a chave primária como referência. Uma inserção adiciona uma linha, uma atualização a reescreve, e uma exclusão a remove — então a tabela no BigQuery espelha a tabela de origem.

O modo Merge do Datastream faz isso nativamente e marca cada linha com um UUID (uma string de ID único) e um timestamp de origem na coluna de metadados. Sem chave primária, não há com o que fazer o match, então a tabela vira append-only: uma exclusão chega como uma linha nova, sinalizada nos metadados, e as consultas seguintes precisam filtrar essas sinalizações por conta própria.

Um pipeline construído na mão precisa fazer essa mesclagem sozinho, porque atualizar linhas no BigQuery significa rodar comandos MERGE, e cada um é uma consulta cobrada. O formato mais comum é carregar cada lote numa tabela de staging, deduplicar pela chave primária e então rodar o MERGE na tabela final. Essa lógica de merge é a maior parte do trabalho na opção DIY.

Quanto custa carregar dados do PostgreSQL no BigQuery?

Carregar dados em batch no BigQuery é gratuito, através do pool de slots compartilhado; você paga por como os dados chegam até lá e pelo armazenamento. Inserções em streaming custam US$ 0,01 por 200 MiB, e a Storage Write API custa US$ 0,025 por GiB depois de um limite gratuito de 2 TiB por mês.

Precificação de ingestão de dados no BigQuery: cargas em batch são gratuitas, streaming é cobrado por volume

Essa divisão explica os preços das ferramentas. Uma ferramenta ELT em batch cobra pelo próprio serviço, enquanto a carga no BigQuery em si não custa nada. Um pipeline de CDC paga pela ingestão via Storage Write API, e paga de novo pelos jobs de merge em segundo plano que incorporam as mudanças nas tabelas de destino, cobrados como computação normal do BigQuery.

O armazenamento é igual nos dois casos: dados carregados são cobrados nas taxas de armazenamento padrão do BigQuery, tenham chegado por batch ou por streaming.

O que pode quebrar uma sincronização de PostgreSQL para o BigQuery?

Um consumidor de CDC pausado pode reter WAL até encher o disco da origem — e esse é só o primeiro de cinco modos de falha para planejar:

• WAL retido. Um slot sem limite mantém WAL para sempre enquanto o consumidor estiver parado. Defina o max_slot_wal_keep_size e acompanhe o atraso do slot desde o primeiro dia.
• Exclusões perdidas. As execuções incrementais do Data Transfer Service e o modo xmin do Airbyte ignoram exclusões. Linhas removidas no PostgreSQL vão se acumulando no BigQuery, a menos que a aplicação use soft-delete ou o pipeline use CDC.
• Lacunas de chave primária. O Datastream transforma tabelas sem PK em append-only e ignora chaves primárias do tipo FLOAT e REAL; o Data Transfer Service limita tabelas sem PK e sem índice a 2.000.000 de registros.
• Mudança de schema. Num pipeline construído na mão, uma mudança de schema na origem provavelmente vai quebrar os jobs de carga. As ferramentas gerenciadas variam: a Erathos detecta novas colunas e as adiciona sozinha no destino.
• Indisponibilidade do destino. O Fivetran retém dados não entregues por até vinte e quatro horas e depois os descarta; uma indisponibilidade mais longa pode forçar uma resincronização histórica, dependendo de quanto WAL a origem conseguiu reter.

Escolha o Data Transfer Service quando dados com algumas horas de atraso forem aceitáveis e exclusões não importarem, o Datastream para CDC nativo do Google, gerenciando os slots você mesmo, ou uma ferramenta gerenciada como a Erathos quando você quiser o checklist de CDC, os retries e o tratamento de schema já resolvidos pra você.

Pule as configurações de WAL e deixe a Erathos cuidar disso

A Erathos se conecta ao PostgreSQL por conexão aberta, IP estático ou túnel SSH, e move os dados para o BigQuery em batch, incremental ou CDC — atualizando a cada 5 minutos no Pro. Sem replication slot pra vigiar, sem comando MERGE pra escrever, e é grátis até 1 milhão de linhas por mês.

Teste a Erathos grátis por 14 dias