Snowflake 的 Postgres 镜像正式可用：和 Databricks Lakebase 并排比一比

Snowflake 10 月 15 日宣布，Snowflake Postgres 的数据镜像正式可用（GA）。¹在 Snowflake 托管的 Postgres 上建一个镜像，表里的插入、更新、删除和 schema 变化就会持续进入 Snowflake，不用再自己搭一套外部复制服务。

Databricks 的 Lakebase 也是托管 Postgres，变更能流进 Unity Catalog 的 Delta 表，湖仓里的表也能同步回来。⁵⁷两家都想去掉应用库和分析平台之间那段自建管道。下面先讲 Snowflake 发布了什么，再把两家放进同一张表。

Snowflake 让 Postgres 自己把变更推出来

镜像靠的是 Snowflake 开源的 Postgres 扩展 pg_lake。它用标准的逻辑复制捕获变更，在数据库内部按事务分批推出，先写成对象存储里的 Apache Iceberg 变更日志，Snowflake 再用 serverless 计算按事务合并进目标表。¹分析平台不用回头去扫应用库。

建镜像只要一次 CREATE_MIRROR 调用。可以选几张表、整个 schema 或整个库，schema 里以后新建的表也会自动加入；目标可以是普通 Snowflake 表，也可以是 Iceberg 表。¹²每张镜像表附带两个对象：保留 7 天变更的 $changes，和把已合并数据与在途变更拼在一起的 $live 视图。¹³

目前只支持 AWS 和 Azure，不能跨账号、跨区域或跨云。²博客没有给价格。厂商称，Ericsson 用它合并了四个旧数据库，数据处理时间减少 99%。¹

并排看：Snowflake 的一致性更完整，Databricks 两个方向都有

	Snowflake Postgres 数据镜像	Databricks Lakebase
成熟度	已正式可用（GA），支持 AWS 和 Azure	Postgres 到湖仓：还在公开预览
怎么同步	Postgres 里的扩展把变更推出来，Snowflake 再合并成表	Postgres 里的扩展把变更写进湖仓的一张流水表
多快能看到	实时视图约 30 秒；目标表默认每 10 分钟合并一次①	约 15 秒写入一批
事务完整吗	目标表完整，多张表一起更新；实时视图可能只看到半笔②	不保证；每行带事务编号，要自己拼回完整事务③
变更历史	只保留最近 7 天④	一直追加保存，但只有流水，最新状态要自己算
改表结构	新表自动加入；不能直接改列的类型	加列、删列、改类型，这张表都会重新全量同步
能同步回 Postgres 吗	还不能，官方只说即将推出	能：湖仓的表可同步回 Postgres，只读，最快 15 秒一次⑤
使用前提	最低档实例不支持；一个实例默认最多 10 个镜像	Postgres 16 到 18 版；表要开启完整行记录；分区表不支持

1. ①实时视图（$live）把已合并的数据和还没合并的变更拼在一起，博客说的"几秒内可见"指的就是它。目标表多久合并一次由合并间隔（refresh_interval）决定，默认 10 分钟，可设 30 秒到 1 天。
2. ②快和完整要二选一：对账、报表查目标表，接受合并间隔带来的滞后；把间隔调短，合并要花的计算就更多。
3. ③事务编号就是每行的 _pg_xid 字段。Databricks 文档没写多表一致，要靠它把同一笔事务在几张表里的变更对齐。
4. ④这 7 天的变更存在 $changes 表里。如果 Postgres 积压的日志太多、复制位置失效，镜像会整表重新同步，这 7 天的历史也会丢。
5. ⑤这些"同步表"在 Postgres 里只读，应用写进去的数据下次刷新会被覆盖；同步速度约每个计算单元每秒 150 行。

表里有三处差别，选型时最容易看漏，下面分开讲。

“几秒内”看到的是 $live 视图，它不保证事务完整

博客说，源库提交的变更几秒内就能在 Snowflake 里读到。¹查询文档把这件事拆成了三层：$changes 随源库变化自动刷新；$live 视图每 30 秒跟着 $changes 更新一次；目标表按 refresh_interval 合并，默认 10 分钟，可以设成 30 秒到 1 天。²³

问题在第二层。文档直说 $live 视图不是事务性的，可能露出半个事务，有的行看得到，有的还没到；需要一致，就查目标表。³所以按默认设置，“快”和“完整”只能挑一个：查 $live，数据是半分钟内的，但一笔转账可能只看到扣款那一行；查目标表，每笔事务都完整，代价是最多约 10 分钟的滞后。

把间隔调短也有代价。$live 每次都要扫描还没合并进目标表的全部 $changes 行，文档推荐的省钱组合是：合并间隔放长，$live 只扫一小段。³我的用法会是：对账、审计、对外报表查目标表；看板和告警这类允许短暂不一致的场景查 $live。

Databricks 的回程给的是流水，当前状态要自己算

Lakebase 往 Delta 的那条路叫 Change Data Feed，目前是公开预览。Lakebase 里的 wal2delta 扩展用逻辑解码读 WAL，大约每 15 秒写一批，每张源表对应一张 lb_<表名>_history Delta 表。⁵它按 schema 配置，schema 里现有和以后新建的表都会自动纳入。⁶

这张表是流水账：每行带变更类型、_pg_lsn、_pg_xid 和时间戳，一次更新记成“更新前”和“更新后”两行。⁵审计喜欢这种形状，改之前是什么、改之后是什么、哪个事务改的，都在一张表里。但它不维护当前状态，文档给了三种自己算的办法：物化视图、Lakeflow 管道，或者 Structured Streaming 加 MERGE。⁵跨表的事务一致性文档没有写；我的理解是，有 _pg_xid 就能按事务把多张表的变更重新对齐，但这一步得你自己做。

反向同步：Databricks 已经能做，Snowflake 还在“敬请期待”

Databricks 的同步表把 Unity Catalog 里的 Delta 表、Iceberg 表、视图和物化视图同步进 Lakebase Postgres，有三种模式：每次全量的 Snapshot，按需或定时的 Triggered，持续流式的 Continuous。⁷Continuous 最短 15 秒一次；Triggered 比每 5 分钟还频繁时，文档提醒会很贵；单表建议在 1 TB 以内。⁷同步表在 Postgres 里只读，⁷适合把湖仓里算好的推荐分数、风控标签送回应用，应用照常用 Postgres 驱动去读。

Snowflake 这一侧，博客只说反向镜像“敬请期待”，没有时间表。¹今天要把 Snowflake 里算出的结果送回 Postgres，还得自己写管道。

怎么选：先看数据要往哪个方向流

• 只需要把应用库的数据拿去分析，团队又已经在 Snowflake 上：镜像已经 GA，多张表按事务一起前进，最省事。按用途选目标表还是 $live，refresh_interval 算进成本。
• 要把湖仓的结果送回应用，或者想要带前后像的完整流水：Databricks 两条路都有，但去程还在预览，上生产前对一遍图 1 最后一行的前提。
• 要长期保留变更历史给审计：Snowflake 的 $changes 只留 7 天，复制槽失效重新快照时增量历史也会丢，³⁴要留一年就自己定期另存。Databricks 的历史表追加写入，文档没设保留期，但当前状态和跨表一致要你自己负责。

两家都把“应用库到分析平台”这段管道收进了平台。差别在于各自把哪部分做完了：Snowflake 做完了一致性，Databricks 先把双向铺好了。选之前，先想清楚你的数据最常往哪边走。