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 的共享存储横向扩展架构已经形成了一个真正的类别。关注其发展态势，但不要急于在预览阶段就将你的运营栈押注在上面。
上一篇 [深入剖析托管 Postgres：Google Cloud SQL for PostgreSQL](/blog/2026/05/12/managed-postgres-examined-google-cloud-sql-for-postgresql/)
