Snowflake Postgres、Lakebase、HorizonDB：选择你需要的锁定模式

# Snowflake Postgres、Lakebase、HorizonDB：选择你想要的锁定效应 来源：https://thebuild.com/blog/2026/05/12/snowflake-postgres-lakebase-horizondb-picking-the-lock-in-you-want/ 在过去十二个月中，三大数据平台公司均推出了基于自定义存储层和“计算横向扩展、共享存储”架构的 Postgres 风格数据库。Snowflake Postgres 已正式发布（GA），基于 Crunchy Data 团队的工作构建，并通过 `pg_lake` 实现湖仓集成。Databricks Lakebase 已在 AWS 上正式发布，并在 Azure 上公开预览，其构建基础是 Neon 引擎以及 Mooncake 的集成工作。Azure HorizonDB 处于仅限受邀用户预览阶段，在架构上最为激进——微软构建了自研引擎，声称支持高达 3,072 个 vCore 和 128 TB 的数据库规模，并在 OLTP 基准测试中表现出原生 Postgres 3 倍的吞吐量。 这三者都与 Postgres 协议兼容。但它们都不是你所关心的那种意义上的“真正的 Postgres”。问题不在于哪个最好——它们针对的是重叠但不同的工作负载，而有意义的答案取决于你的环境状况，而非它们本身。 ## 真正的决策问题 第一个诚实的问题是：**你目前标准化的数据平台是什么？** 如果你的分析仓库是 Snowflake，那么答案就是选择 Snowflake Postgres，或者不使用任何托管的云原生 PG。如果你的分析平台是 Databricks，那么答案就是 Lakebase，或者不使用任何托管的云原生 PG。如果你是使用 Azure 虚拟机且对此感到厌倦的用户，那么答案就是 HorizonDB，或者通过私有链接使用其他选项（但需附加一些限制条件）。 营销材料会告诉你，每款产品都是操作型与分析型数据融合的未来。它们在某种程度上是正确的，因为无论选择哪一款，都能在你已付费的平台上实现这种融合。对于这三者而言，跨平台的故事是完全相同的：这只是一张带有额外步骤的跨云出口流量账单。 这就是决策框架。其余内容则是你做出决定所需的技术细节。 ## 它们究竟是什么 **Snowflake Postgres** 是这三者中最“像 Postgres”的产品。其引擎明显具有 PG 特征，扩展生态故事较为合理，通过 `pg_lake` 实现的湖仓集成设计确实出色。`pg_lake` 是开源的，可与任何 Postgres 配合使用，这意味着 Snowflake 内部的版本并非绑定性功能——你可以在原生 PG 上进行原型开发，随后再迁移。其宣传点是“你的操作数据与分析数据共存，且操作侧是一个真正的 Postgres”。这一宣传点站得住脚。代价是你现在必须从 Snowflake 购买 Postgres，而 Snowflake 的定价体系就是 Snowflake 的定价体系。 **Lakebase** 对开发者而言是这三者中最有趣的产品。源自 Neon 的分支模型是一个真正的特性：为 CI/CD 提供即时数据库分支、将时间点恢复（PITR）作为常规操作而非灾难恢复手段、以使得缩容至零成本极低的方式分离计算与存储。其宣传点是“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 仍舒适地运行在单个高性能主节点加几个副本的配置上，“我将来可能需要 3,000 个 vCore”并不是今天购买数据库的理由。 有趣的进展不是存在这三款产品，而是它们都在相同的十八个月内出现。Postgres 的共享存储横向扩展架构已收敛为一个真实的类别。观察其发展态势。不要成为第一个在预览阶段就将操作栈押注其上的人。