Snowflake implementa espelhamento de dados do Postgres para análise
Data Mirroring: CDC push-based do Postgres para Snowflake
A Snowflake publicou um artigo técnico detalhando como construiu o data mirroring, uma nova funcionalidade do Snowflake Postgres (em public preview) que replica dados transacionais do Postgres para tabelas analíticas na Snowflake de forma automática, com baixa latência e consistência transacional.
O problema com CDC tradicional
O mecanismo nativo de CDC do Postgres (logical decoding) expõe mudanças como um stream de rede, mas transfere toda a complexidade para o consumidor externo: backfill, mudanças de schema, snapshots, recuperação de falhas, alinhamento entre snapshots e mudanças etc. O sistema externo não conhece o estado interno do Postgres, o que gera pipelines frágeis.
A solução: push em vez de pull
A Snowflake criou a extensão snowflake_cdc que roda dentro do Postgres e empurra batches de mudanças diretamente para tabelas Apache Iceberg (Parquet comprimido) em object storage (S3). Como a extensão roda dentro do Postgres, ela tem visibilidade total sobre o estado do banco - coordenando schema changes, snapshots e DML/DDL de forma integrada.
Timeline de replicação em 4 estágios
- Write – a escrita modifica a tabela e o WAL
- Decode – WAL passado é traduzido para mudanças row-level
- Capture – mudanças são capturadas em batches e gravadas nos change logs Iceberg
- Apply – batches são aplicados nas tabelas de destino na Snowflake
Transações como bloco fundamental
O sistema usa transações em ambos os lados: no Postgres, um batch de dados + schema changes é escrito nos change logs Iceberg em uma única transação (via pg_lake); na Snowflake, múltiplos batches são aplicados em uma única transação, movendo todas as tabelas até exatamente um boundary transacional do Postgres. Isso preserva foreign keys e join correctness.
Vantagens sobre a abordagem upsert
Em vez de converter tudo em upserts (custoso com storage colunar), o design transacional permite usar inserts puros (append) e deletes, tornando workloads insert-heavy extremamente rápidos e eficientes em custo.
Live views
Combinam mudanças ainda não aplicadas nos change logs com os dados das tabelas de destino, permitindo queries com lag abaixo de um minuto mesmo sem aplicar batches frequentemente. Filtros e projeções são empurrados para a camada de storage (predicate pushdown).
Duas formas de unificar workloads
- Data mirroring (public preview): replicação automática e contínua, setup único.
- Postgres for your data lake (GA): movimento de dados controlado pelo desenvolvedor via SQL, usando formatos abertos como Iceberg.