来源https://thebuild.com/blog/2026/04/24/postgres-goes-to-the-lake-two-ways/Postgres 迈向数据湖的两种方式去年发生的收购案如今已转化为实际产品这使得我们首次能够将 Snowflake 和 Databricks 的“Postgres-in-the-lakehouse”数据湖仓一体中的 Postgres战略作为真实存在的事物进行比较而不仅仅停留在营销材料层面。这两起收购分别是Snowflake 于 2025 年 6 月收购了 Crunchy Data约 2.5 亿美元并于同年 11 月在 Snowflake-Labs 下以开源形式发布了pg_lake。Databricks 于 2025 年 5 月收购了 Neon约 10 亿美元并推出了 Lakebase其 AWS 版本于今年早些时候正式可用Azure 版本目前处于公开预览阶段。这两笔交易在数周内相继完成并最终产生了两种截然不同的架构。pg_lake将数据湖带给 Postgrespg_lake是一个 Postgres 扩展它允许 Postgres 后端直接读取和写入 Iceberg 表以及原始对象存储文件S3、GCS、Azure Blob。它更像是一个功能强大的外部数据包装器foreign data wrapper而不是其他什么东西。针对 Iceberg 表的查询会经过 Postgres 的规划器和执行器。事务仍然是 Postgres 自身的事务——但事务中的更改只会提交到本地的 Postgres 关系而不会提交到 Iceberg 表本身。对 Iceberg 数据的读取是在查询时进行联邦的。基于此技术栈的托管服务 Snowflake Postgres 已于今年春季早些时候正式可用。其卖点很清晰你编写 Postgres 查询你的SELECT语句将一个本地 OLTP 表与一个存放在 S3 上的 Iceberg 表进行连接Postgres 规划器能同时看到这两者。Lakebase将 Postgres 带入数据湖Lakebase就是Neon。Neon 的架构——存储与计算分离、写时复制分支、前端为 pageserver 后端为对象存储——已被重新部署到 Databricks 的基础设施之上。其结果就是一个无服务器的 Postgres它内置于湖仓一体之中而非外部附加。运营数据和数据分析数据位于同一个系统内因为同一个存储层同时容纳了它们。2026 年 4 月Lakebase 为其自动扩展项目增加了客户管理的密钥——这更多是为了满足合规性要求而非架构上的转变但这标志着 Lakebase 已进入适合企业使用的领域。哪一种方案解决什么问题这两者并非同一产品的不同包装。它们解决的是不同的问题。pg_lake适用的场景当你拥有一个正常运行的 OLTP Postgres 和一个正常运行的湖仓一体并且你希望它们在查询时能够进行连接。Postgres 规划器是成本评估的界面联邦意味着事务边界止于 Iceberg 边缘。如果你的分析表确实是用于分析的——数据量大、主要是追加写入、以聚合方式查询——这将会工作得很好。如果你的分析表实际上是热门的 OLTP 表而某人几个季度以来一直承诺要将其“迁移到数据仓库”那么pg_lake会令你失望。Lakebase 适用的场景当你希望运营工作负载从一开始就运行在湖仓一体内部时。如果你的用例涉及代理agentic——启动一个全新的分支让代理去操作然后将其丢弃——那么存储-计算分离和分支功能就变得至关重要。这种工作负载在pg_lake上根本无法如此干净地实现。两者都无法替代对方也都无法替代普通的、自托管的 Postgres。它们在故障域、规划器界面和事务语义上的差异足够大以至于选择取决于架构而非供应商偏好。该怎么做先搞清楚你的问题是什么。如果你的答案是“我的 OLTP 和我的数据湖是不同的系统我希望 Postgres 能够查询两者”那么请关注pg_lake。如果你的答案是“我希望 OLTP 形态的 Postgres 内置于我的湖仓一体之中”那么请关注 Lakebase。不要让任何销售宣传告诉你他们在同一个维度上竞争。