Snowflake在7月23日的一篇工程博客里，把自己新做的Postgres复制功能称作"clockwork"——一台设置一次就能永远走下去的时钟。这个功能叫Data Mirroring，目前是公开预览阶段。它的做法是往Postgres里塞一个叫snowflake_cdc的扩展，让变更数据直接从数据库内部推送进Apache Iceberg表，再由Snowflake端以事务方式自动合并进目标表。听起来像是解决了CDC领域一个老大难问题：让复制不再依赖外部连接器和人工兜底。
这个判断部分成立。传统CDC工具比如Debezium、AWS DMS、Fivetran，做法基本是"拉"——从Postgres的逻辑解码接口把变更流拉出来，丢给Kafka或者其他中间件，再自己处理schema变更、快照对齐、故障重启这些脏活。Snowflake这次反过来，把状态感知能力做进了源库扩展本身，变更由Postgres主动push进对象存储，而不是被动等外部工具来拉。架构上这确实比"裸机版logical replication"更完整。但博客里没说的，恰恰是判断这套系统能不能进生产环境的几个硬指标。
四步流水线：从WAL到Iceberg表
Snowflake把每一次写入拆成四个阶段：Write（写入WAL）、Decode（解码成行级变更）、Capture（打包进变更日志）、Apply（合并进目标表）。这四步各自独立运行，靠一个叫metalog的记录来对齐事务边界和schema变更顺序，避免变更乱序或者schema变更卡在中间状态。
这套设计的好处很直接：insert密集型的大表，因为变更只需append进变更日志，不用像传统upsert那样逐行去匹配目标表，复制效率会高很多。目标表如果要低延迟查询，还有一个$live视图，把已落地数据和还没合并的变更日志实时拼在一起读——文档给出的延迟量级是约30秒。这个数字很关键，Snowflake自己的博客里完全没提，只用"well below a minute"这种模糊表述带过。30秒级的延迟对刷新仪表盘够用，但如果有人指望拿它做准实时的读写分离或者热备切换，这个量级就得提前打好预防针。
和Fivetran、Debezium比，创新点在哪
"把CDC推进数据湖再事务化应用"这个思路，本身不是Snowflake发明的。Debezium配合Kafka、再用Flink或Spark写进Iceberg，早就是一种常见架构，本质上也是"一批变更等于一个Iceberg快照"。Snowflake真正做的事，是把这条本来要自己拼凑三四个组件的链路，收进一个托管扩展加一个serverless应用层，用户不用再自己维护Kafka集群和合并逻辑。
- 结论.这更像是把已有的"push进湖仓再提交"范式做成了开箱即用的托管产品，而不是发明了新范式。
值得一提的是，Snowflake手里其实有两条并行的产品线，很容易被读者混为一谈。Data Mirroring是持续、整表、自动化的复制，目前公开预览；Postgres for your data lake（也就是开源的pg_lake扩展的托管版）已经正式可用（GA），走的是开发者用SQL手动控制数据搬迁的路线，适合选择性、非全表同步的场景。一个是"设置一次就自动跑"，一个是"你写SQL决定何时搬"，选错工具会白折腾。
官方没答的问题，才是决定能不能上生产的问题
Snowflake博客反复强调"transactional consistency"和"exactly-once"，这类措辞很容易让人觉得整个系统等同于强一致性的实时镜像。但CDC类产品的行业惯例是最终一致（eventual consistency）——变更会到，但到达和可见之间总有窗口。"transactional mirroring"这个说法描述的是应用侧的事务边界处理方式，不等于跨系统的严格实时一致性保证，这两者不该被混着理解。
复制产品的说明书里，形容词永远比免责条款好看。
真正决定这套系统能不能替换现有Fivetran或Debezium管道的，是几个博客完全没有展开的细节：跨多张表的Postgres事务，在Snowflake端能不能做到原子可见；列重命名、主键变更这类高风险DDL，扩展是不是真能自动处理还是仍需人工介入；高频update/delete的表在Iceberg变更日志加MERGE的模式下，成本曲线会不会比传统upsert更陡；复制槽断连超过24小时，恢复机制是自动重新快照还是需要手动干预。这些问题，任何一个团队在拿它做POC之前都该逐条向Snowflake工程团队要实测数据，而不是照单全收博客里的比喻。
- 风险.延迟、跨表原子性、DDL治理、断连恢复这几项官方博客均未给出量化数据，直接上生产前需要自行验证。
对已经在用Snowflake Postgres、并且分析需求以整表同步为主的团队，这个公开预览值得现在就拿真实workload测一遍——尤其是测insert密集型大表的成本表现，这是它相对传统CDC工具最有把握的场景。但如果业务里有大量高频update/delete表，或者需要跨表事务级别的强一致性保证，更现实的做法是等它转正式版（GA），并且拿到独立的延迟和成本基准数据之后再做决定。