The "Zero-ETL" Illusion: Snowflake's Push-Based CDC Postgres Extension vs. Architectural Reality
Snowflake’s introduction of data mirroring for its Postgres service represents an ambitious attempt to solve the historical fragility of Change Data Capture (CDC). By shifting from a traditional "pull-based" replication model to an extension-driven "push-based" model, Snowflake aims to turn database replication into a seamless, transactional process.
However, systems and database engineers are greeting this "zero-ETL" promise with deep skepticism. While the engineering behind pushing transactional batches into Apache Iceberg tables is elegant, practitioners are wary of "magic" infrastructure abstractions, citing past operational nightmares with similar cloud-native replication bridges.
Moving CDC Into Postgres via pg_lake
Traditional CDC pipelines rely on external tools (like Debezium) to pull and decode Postgres Write-Ahead Logs (WAL), a process highly vulnerable to schema changes, network drops, and snapshot conflicts. Snowflake’s solution is a new Postgres extension, snowflake_cdc, which runs background workers directly inside Postgres.
These workers capture change logs, align them with schema updates, and push them as compressed Parquet files into Apache Iceberg tables on object storage. While the underlying table engine pg_lake is open-source, the critical replication and CDC components (snowflake_cdc) remain closed-source and tied to Snowflake’s managed ecosystem.
"Although pg_lake is open source, worth noting that it heavily refers to but is missing CDC capabilities. There's a bunch of comments/links to a closed [repository]..." — jauntywundrkind on Hacker News
The Zero-ETL Skepticism
The primary source of skepticism among engineers is the track record of "zero-ETL" integrations. Many teams have been burned by similar promises from cloud providers—most notably AWS Aurora’s Zero-ETL integration with Redshift—which frequently fail or halt under basic schema migrations, requiring extensive manual intervention.
Furthermore, engineers express a fundamental discomfort with adopting proprietary, SaaS-only database extensions that lock their core data pipelines into a single vendor's ecosystem with no self-hosted fallback.
"Aurora zero etl was a nightmare for us. Almost any schema changes require a VACUUM FULL for it to continue functioning. On a few occasions, it just stopped running without an obvious explanation..." — bastawhiz on Hacker News
"As much praise as some people give to it, I feel deeply uncomfortable with an idea of SaaS-only DB tech that you don't have an option to self host" — arvyy on Hacker News