Snowflake Postgres、Lakebase、HorizonDB 登场，如何选“锁定”方案？

2026 年 5 月 12 日 阅读时长 4 分钟在过去的十二个月里三家大型数据平台公司推出了具有自定义存储层和“横向扩展计算、共享存储”架构的 Postgres 风格数据库。Snowflake Postgres 已正式发布它基于 Crunchy Data 团队的工作构建以 pg_lake 作为数据湖仓的连接点。Databricks Lakebase 在 AWS 上已正式发布在 Azure 上处于公开预览阶段它基于 Neon 引擎并结合了 Mooncake 集成工作。Azure HorizonDB 处于邀请制预览阶段在架构上是三者中最激进的——微软构建了自己的引擎宣称支持多达 3072 个 vCore 和 128 TB 的数据库并且在 OLTP 方面的吞吐量是原生 Postgres 的 3 倍。这三款数据库都与 Postgres 网络协议兼容但从对你来说重要的层面看它们都不是真正的 Postgres。问题不在于哪个最好——它们针对的工作负载有重叠但又各有不同有意义的答案取决于你的使用环境而非数据库本身。实际的决策问题坦率地说第一个问题是**你已经标准化使用的是哪个数据平台** 如果你的分析型数据仓库使用的是 Snowflake那么答案就是 Snowflake Postgres否则就没有托管的云原生 PG 可选。如果你的分析平台是 Databricks那么答案就是 Lakebase否则也没有托管的云原生 PG 可选。如果你是使用 Azure VM 且对此感到厌烦的用户那么答案就是 HorizonDB或者通过专用链接使用其他数据库但可能会有一些限制。营销材料会告诉你每一款都是运营和分析融合的未来。从某种意义上说它们是对的因为在你已经付费的平台内它们都能实现这种融合。但这三款数据库的跨平台情况都一样跨云出口费用会增加额外成本。这就是决策框架。接下来的内容是你做出选择所需了解的技术细节。各数据库的实际情况Snowflake Postgres是三者中最“像 Postgres”的。其引擎明显是 PG扩展功能合理通过 pg_lake 进行的数据湖仓集成设计得非常出色。pg_lake 是开源的可用于任何 Postgres这意味着 Snowflake 内的版本并非专属功能——你可以在原生 PG 上进行原型开发然后迁移。其宣传点是“你的运营数据与分析数据相邻且运营端是真正的 Postgres”这个宣传是站得住脚的。代价是你现在要从 Snowflake 购买 Postgres而 Snowflake 的定价就是其既定的价格体系。Lakebase对开发者来说是三者中最有趣的。基于 Neon 的分支模型是一项实用功能支持 CI/CD 的即时数据库分支、将时间点恢复作为常规操作而非灾难恢复流程并且以一种使缩容至零成本较低的方式实现计算与存储分离。其宣传口号是“AI 时代的 Postgres”实际上就是指在 Databricks 工作区旁边使用 Postgres。如果你使用 Databricks这是一款不错的产品如果你不使用那它就显得有些奇怪。Azure HorizonDB在架构上最为雄心勃勃。微软没有收购 Postgres 公司而是从头构建了一个支持 Postgres 网络协议和 SQL 接口的存储引擎。如果其性能数据在独立测试中得到验证那是可信的——共享存储/横向扩展计算架构在大规模场景下确实比单主 Postgres 表现更优。代价是“网络协议兼容”和“真正的 Postgres”是两回事两者之间的差距大小取决于你对扩展和工具的依赖程度。实际会失去的东西这部分在供应商材料中往往被一笔带过。使用这些数据库你会在以下方面有所损失**扩展功能**每个分支版本都只支持一部分扩展。PostGIS 支持通常较好但不太常见的扩展就不一定了。任何自带后台进程的扩展都有不确定性。**逻辑复制**三者处理逻辑复制的方式不同。Snowflake Postgres 最接近原生行为Lakebase 的分支模型和 HorizonDB 的共享存储架构对逻辑解码的影响尚未完全文档化。如果你目前正在使用逻辑复制这是首先要测试的内容。**运维工具**pg_basebackup、pgBackRest 和 Patroni 都不适用。你现有的运维经验在查询方面大多可以迁移但在其他方面基本无用。**可预测的升级路径**每个供应商控制着你升级 PG 版本的时间。你无法按照自己的计划测试 PG 19。实际会获得的东西你将获得自行运行 Postgres 无法实现的运营规模。这些都不是小成就。微软为 HorizonDB 所宣称的多区域提交延迟很难通过其他方式复制。Lakebase 的分支功能非常实用。Snowflake 的数据湖仓与 OLTP 的集成比“在 Postgres 和 Snowflake 之间进行 ETL”更紧密。你还将建立与供应商的合作关系这意味着既有好处也有弊端。建议选择与你已使用的相邻数据平台配套的数据库不要假装你有实际上并不存在的选择。如果你没有相邻的数据平台那么在实际实例上运行真正的 Postgres或者使用传统的托管服务如 Aurora、Cloud SQL、Azure Database for PostgreSQL、Crunchy Bridge、EDB、pgEdge。云原生横向扩展的故事是真实的但它只适用于一小部分工作负载。大多数生产环境中的 Postgres 仍然可以舒适地运行在一个强大的主节点和几个副本上“某天可能需要 3000 个 vCore”并不是现在购买数据库的理由。有趣的是这三款数据库在短短 18 个月内相继出现。Postgres 的共享存储横向扩展架构已经形成了一个真正的类别。关注其发展态势但不要急于在预览阶段就将你的运营栈押注在上面。上一篇 [深入剖析托管 PostgresGoogle Cloud SQL for PostgreSQL](/blog/2026/05/12/managed-postgres-examined-google-cloud-sql-for-postgresql/)