Snowflake Postgres, Lakebase, and HorizonDB: Navigating the New Wave of Cloud-Native Postgres

数据库领域正在发生转变。在过去的一年里，三大最大的数据平台提供商——Snowflake、Databricks 和 Microsoft——都发布了“Postgres 风格”的数据库。虽然它们都声称与 PostgreSQL 协议兼容，但它们与原生引擎有着本质的区别，采用了自定义存储层和“计算扩展、共享存储”架构。

这些产品——Snowflake Postgres、Databricks Lakebase 和 Azure HorizonDB——旨在弥合操作型（OLTP）和分析型（OLAP）工作负载之间的鸿沟。然而，它们之间的选择很少是关于技术上的绝对优越性，而是关于你的数据已经存在于何处。

The Ecosystem Lock-In Framework

在评估这些平台时，首要问题不是“哪个数据库最好？”，而是“你已经标准化使用了哪种数据平台？”

  • Snowflake Users: 如果你的分析仓库是 Snowflake，那么 Snowflake Postgres 是获得托管云原生 PG 体验的逻辑选择。
  • Databricks Users: 如果你的分析平台是 Databricks，那么 Lakebase 是天然的契合点。
  • Azure Shops: 对于那些重度投资于 Azure 生态系统且厌倦了管理 VM 的用户，HorizonDB 提供了一个深度集成的替代方案。

正如作者所指出的，虽然这些供应商在营销“操作型与分析型融合”，但这种融合仅发生在它们各自的专有围墙之内。在这些平台之间移动数据仍然是一项涉及高额云流出费用的昂贵活动。

Technical Breakdown: Three Different Approaches

尽管它们共享 Postgres 协议兼容性，但这三种产品的架构哲学却大不相同：

Snowflake Postgres

这是三者中最“像 Postgres”的一个。它基于 Crunchy Data 团队的工作构建，利用 pg_lake 作为其 lakehouse 钩子。由于 pg_lake 是开源的且与原生 Postgres 兼容，它允许开发者在标准 PG 上进行原型设计，然后迁移到 Snowflake 而不会被特定的功能所困。这里的主要权衡是价格，因为你必须遵循 Snowflake 的特定成本结构。

Databricks Lakebase

Lakebase 对开发者特别有吸引力，因为它采用了源自 Neon 的分支模型。这使得 CI/CD 可以实现即时数据库分支，并将点对点恢复从灾难恢复程序转变为标准操作。它将计算与存储分离，以实现廉价的 scale-to-zero 能力。然而，其价值主张与其 Databricks 工作区紧密绑定。

Azure HorizonDB

HorizonDB 在架构上最为激进。Microsoft 并没有修改现有引擎，而是从头开始构建了一个支持 Postgres 协议的存储引擎。这种方法允许实现大规模扩展——声称支持高达 3,072 vCores 和 128 TB 数据库——并且基准测试显示其在 OLTP 工作负载上的吞吐量是原生 Postgres 的 3 倍。这里的风险在于“协议兼容”与“实际上的 Postgres”之间的差距，这在当你重度依赖特定扩展或深度工具链时会变得至关重要。

The Hidden Costs of "Postgres-Flavored"

供应商的营销往往掩盖了从原生 PostgreSQL 转向专有扩展版本时所失去的东西：

  • Extension Support: 虽然 PostGIS 通常得到很好的支持，但不太常见的扩展是一个赌博。任何需要其自身后台工作进程（background worker）的扩展都特别危险。
  • Logical Replication: 每个平台处理这种方式都不同。Lakebase 的分支模型和 HorizonDB 的共享存储架构为逻辑解码引入了尚未完全记录的复杂性。
  • Operational Tooling: 标准工具如 pg_basebackup, pgBackRest, 和 Patroni 基本上是无关紧要的。你的查询知识可以迁移，但你的运维运维经验无法迁移。

Final Verdict: When to Scale Out

对于绝大多数生产环境的工作负载，一个强大的主节点加几个副本就足够了。承诺的“3,000 vCores”是一种很少有人真正需要的奢侈品。

如果你还没有一个占主导地位的相邻数据平台（Snowflake, Databricks, 或 Azure），建议坚持使用实际的 Postgres 实例或使用成熟的的托管服务，如 Aurora, Cloud SQL, 或 Crunchy Bridge。

共享存储扩展架构融入一个公认的类别是一个重要的行业趋势。然而，对于大多数工程师来说，最稳妥的做法是避免成为第一个将运维栈将运维栈押注在预览版产品上的先行者。

Sources