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

資料庫領域正在發生轉變。在過去一年中，三大數據平台供應商——Snowflake、Databricks 與 Microsoft——都推出了「Postgres 風味」的資料庫。雖然它們都聲稱與 PostgreSQL 具有 wire-compatibility，但它們與標準引擎有本質上的不同，使用了自定義的儲存層和「擴展運算、共享儲存」架構。

這些產品——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 wire compatibility，但這三款產品的架構哲學卻大不相同：

Snowflake Postgres

這是三者中最「像 Postgres」的一個。它基於 Crunchy Data 團隊的工作構建，利用 pg_lake 作為其 lakehouse 鉤子。由於 pg_lake 是開源的且與標準 Postgres 相容，它允許開發者在標準 PG 上進行原型設計，然後遷移到 Snowflake 而不會被困在特定的功能中。這裡的主要權衡是在於價格，因為您必須遵循 Snowflake 的特定成本結構。

Databricks Lakebase

Lakebase 對開發者來說特別具有吸引力，因為它具有源自 Neon 的分支模型（branching model）。這使得 CI/CD 可以實現即時的資料庫分支，並將點對時間恢復（point-in-time recovery）從災難恢復程序轉變為標準操作。它將運算與儲存分離，以實現廉價的 scale-to-zero 能力。然而，其價值主張與 Databricks workspace 的綁定程度很高。

Azure HorizonDB

HorizonDB 在架構上最具侵略性。Microsoft 並非修改現有的引擎，而是從頭開始構建了一個支援 Postgres wire protocol 的儲存引擎。這種方法允許大規模擴展——聲稱可達 3,072 vCores 與 128 TB 資料庫——且基準測試顯示其在 OLTP 工作負載上的吞吐量是標準 Postgres 的 3 倍。這裡的風險在於「wire compatible」與「實際上的 Postgres」之間的差距，如果您高度依賴特定的擴展功能或深度工具，這點會變得至關重要。

The Hidden Costs of "Postgres-Flavored"

供應商的行銷往往忽略了當您從標準 PostgreSQL 轉向專有的擴展版本時會失去什麼：

  • Extension Support: 雖然 PostGIS 通常得到良好的支持，但較不常見的擴展功能則是一場賭博。任何需要其自身背景工作程序（background worker）的擴展功能都特別具有風險。
  • Logical Replication: 每個平台處理此項的方式各不相同。Lakebase 的分支模型與 HorizonDB 的共享儲存架構為邏輯解碼（logical decoding）引入了尚未完全記錄的複雜性。
  • Operational Tooling: 標準工具如 pg_basebackup、pgBackRest 與 Patroni 基本上不再適用。您的查詢知識可以遷移，但您的運作維護經驗（operational muscle memory）無法遷移。
  • Upgrade Control: 您失去了自行決定測試並遷移到新版本 Postgres（例如 PG 19）的時間表；您必須聽命於供應商的產品路線圖。

Final Verdict: When to Scale Out

對於絕大多數的生產環境工作負載，單個強大的主節點搭配幾個副本（replicas）就足夠了。所謂的「3,000 vCores」是一種少數人真正需要的奢侈品。

如果您尚未擁有一個主導的相鄰數據平台（Snowflake、Databricks 或 Azure），建議您堅持使用實際的 Postgres 上的實際實例，或使用成熟的託管服務，如 Aurora、Cloud SQL 或 Crunchy Bridge。

共享儲存擴展架構向一個公認的類別轉變，是一個重要的行業趨勢。然而，對於大多數工程師來說，最安全的做法是避免成為第一個將運作堆棧（operational stack）押注在預覽版產品上的先行者。

Sources